Idea Phoca Cart

Ano, unikátní klíče:

ALTER TABLE `products`
ADD PRIMARY KEY (`id`),
ADD UNIQUE KEY `eanx` (`ean`),
ADD UNIQUE KEY `isbnx` (`isbn`);

Při ukládání produktů v Joomle! by problém být neměl, tam to je tak, že pokud existuje ID, pak je to standardní UPDATE, a pokud neexistuje, je to INSERT - vždy se jedná o jeden řádek. Při zobrazování (SELECT) by snad taky neměl být problém.

Konrétně v Phoca Cart jsou tyto možné klíčové sloupce:

`sku` varchar(255) NOT NULL DEFAULT '',
`upc` varchar(15) NOT NULL DEFAULT '',
`ean` varchar(15) NOT NULL DEFAULT '',
`jan` varchar(15) NOT NULL DEFAULT '',
`isbn` varchar(15) NOT NULL DEFAULT '',
`mpn` varchar(255) NOT NULL DEFAULT '',

Aby jsme to nepřeháněli, můžeme vybrat např. SKU a EAN. Jenže co to Japonci (JAN), univerzálové (UPC), výrobci (MPN) a nebo dokonce knihovníci (ISBN)?

V Joomle by asi problém nebyl, ale nevím jak je to s reálnou jedinečností takových kódů jako ISBN nebo MPN - u toho MPN bych o tom pochyboval, tam se to podle mně může potkat u dvou různých výrobců. ISBN jsem se tuším také s někým bavil, kdo mi tvrdil, že ty kódy se opakují, např. na různá vydání stejné knihy (ale s jiným obalem, cenou, někdy třeba i s revidovaným obsahem - tedy jiné položky).

Jestli by nebylo rozumnější raději obětovat výkon při importu a dělat jej dvěma dotazy, než být příliš restriktivní v databázi.

Třeba Firebird to má v SQL vyřešené daleko lépe, tam se u UPDATE OR INSERT určuje podle čeho se má řádek dohledat, MySQL v tom není moc univerzální

Jestli by nebylo rozumnější raději obětovat výkon při importu a dělat jej dvěma dotazy, než být příliš restriktivní v databázi.

Myslíš něco jako:

$result = mysql_query("update products set title='test' where sku='111';");
if (mysql_affected_rows()==0) {
$result = mysql_query("insert into products (title, sku) values ('test','111');");
}

s tím, že where může být variabilní (nastavitelné přes parametr, tedy podle toho co uživatel používá) :idea:

No vida, to mě ani nenapadlo mysql_affected_rows - ale to by to možná vyřešilo ještě elegantněji.
Já myslel klasický select a pak buď insert nebo update, ale pravda je, že takhle by se v ideálním případě ušetřila polovina dotazů.

Takhle to vypadá velmi slibně, variabilní where - ať si každý rozhodne jestli je pro něj důležitý SKU nebo EAN (popř. jiný kód), a jedinečnost ať si hlídá sám... Teoreticky by šlo ještě kontrolu na jedinečnost provádět jen v PHP - v JTable, také podle nastavení. Pak by nemusel být unique index, a jen ukládání by se zpomalilo o dotaz navíc.

No, dívám se na různý články, jak efektivně importovat data z CSV a vůbec nikdo nikde nepočíta s updatem. Prostě při importu se vymaže kompletně tabulka "truncate table" a pak se v php foreachem naskládá INSERT a ten se vloží.

Neřeší se UPDATE, jeden skript by měl zvládnout tisíce řádku, takže se neřeší ani stránkování.

Pokud bychom řešili i update, musí to mít i stránkování, tedy např. přes AJAX posílat posílat určitý počet řádků. Jenže tam zase může být v tom, že při každý ajax instanci se otevírá soubor, což je taky na nic


Jinak těch možností jak importovat CSV je opravdu hodně, dokonce se to dá zvládnout i s načtením souboru jen v mysql (LOAD DATA INFILE)

A tohle je hodně zajímavý (přes dočasnou tabulku i možnost updatu):

stackoverflow.com/questions/10253605/imp...-one-column-in-table

EDIT: zajímavý to je, ale bohužel kombinace updatu a různých sloupců, podle kterých se dá updatovat s LOAD DATA INFILE asi nepůjde, protože ta funkce nezná WHERE:

Zvládne updatovat pomocí on duplicate key update ale už nezvládne updatovat podle zvoleného sloupce

Takže asi nezbývá nic jinýho, než PHP, načtení celýho CSV. a zkusit to smyčkou projet vše naráz.

No TRUNCATE a INSERT si moc nedokážu představit. Soubor by musel vždy obsahovat kompletní informace, včetně ID, ale i třeba dalších průběžně kalkulovaných sloupců. Teoreticky je to samozřejmě dobrá a rychlá věc, prakticky podle mně dost nepoužitelné.

U připojování externích souborů je zas potřeba brát ohled na to, co je reálně možné na běžném hostingu. NEznám do podrobna tuhle funkci, ale obávám se, že na normálním hostingu to asi ani nepůjde použít.

Nejrozumnější mi přijde opravdu zkusit to PHP, popř. pak otestovat výkonost (ale nebál bych se jí), případně fajnšmekrovsky doplnit AJAX. Pokud to bude CSV tak opětovné otevření souboru nebude nijak zvlášť velká zátěž (při čtení po řádkách, ne komplet načtení do paměti). Ono staré dobré CSV má ještě pořád hodně výhod oproti moderním XML, JSON a jiným formátům