Idea Phoca Cart

No, ono to nakonec PHP bude muset být a vše po jednom řádku - neuvědomil jsem si, že hodně sloupců (kategorie, atributy, specifikace) jsou propojeny přes referenční tabulky. Takže jak u importu tak exportu se nebude pracovat jen s jednou tabulkou ale více tabulkami najednou.

Omlouvám se, že Vám do toho zasahuji. Já bych při importu CSV z opatrnosti použl dočasnou tabulku do které bych všechno nasypal (nový i update) a následně zpracoval. V dávné dřevní době jsem řešil také import CSV a použíl jsem dokonce dvě dočasné tabulky. Do jedné jsem nasypal import a druhou jsem použil jako zálohu pro opravované záznamy. V případě chyby nebyl problém se vrátit k původním datům. Je pravda, že se jednalo o Pascal a datbáze byla Paradox, ale základní princip je stejný.

No ono MySQL bez transakcí se v tomto ohledu moc od Paradoxu neliší A Pascal bude ve zpracování CSV určitě výkonější než PHP.

Je pravda, že se tato technika taky používá, obvykle hlavně z důvodu snížení přenosu dat, mezi klientem a SQL serverem, v podstatě vše z CSV nasypat do jakési TMP tabulky a pak už pracovat čistě v rámci SQL. Vidím tam ale problémy s kolizemi mezi různými uživateli (když se dva rozhodnou cosi aktualizovat naráz). V tomto případě by se navíc podle mně ani moc neušetřilo výkonu. Stejně by nakonec došlo k procházení řádek po řádku, jen z jiného zdroje.

Pro "zálohování" má dnes Joomla již vlastní princip verzování - ten by byl možná zajímavý zapracovat...

Současnou práci bych řešil zamykáním tabulky.

To zamykání by bylo určitě rozumný. Co se týče dočasný tabulky, tak tam nevím, protože my nebude pracovat pouze s jednou tabulkou. Kromě produktů, to bude taky referenční tabulka pro kategorie, ale taky pro atributy a její referenčí tabulka pro hodnoty: Tričko (ID produktu) -> Barva (atribut) -> Červená (hodnota). Taky specifikace, dodatečné obrázky, atd.

Zpracování jednoho řádku možná bude tak náročný, že z hlediska paměti [strike]možná bude lepší obětovat otevírání souboru na vícekrát[/strike], např. po 100 položkách, pravděpodobně přes ajax - zjistit počet řádků v CSV a AJAXEM provádět postupný import (stránkování) - [strike]ale tady nám vzniká další problém, kam uložit CSV soubor mezi jednotlivýmy kroky stránkování[/strike].

Což ale může vyřešit právě dočasná - spíš nedočasná tabulka, příklad:

- Bude existovat standardní tabulka "import"
- CSV soubor se nahraje na server - všechny řádky se vloží do tabulky "import" - rychlý INSERT
- začnou se převádět data z tabulky "import" do tabulky "produktů" a jejich referenčních tabulek - např. po 100 řádcích

Tím pádem se nám řeší problém s otevíráním souboru CSV - ten bude otevřen jen jednou při importu do tabulky "import"
Stránkování se nám take zjednoduší - zase nemusíme otevírat CSV kvůli zjištění počtu položek - protože budeme znát počet řádků v tabulce "import"
Tabulka "import" se před každým importem prostě vymaže pomocí TRUNCATE - tím pádem počet řádků nebude ovlivněn např. nějakým "zbytkem"
Tabulku "import" je taky možný zamčít pro zápis a odemčít až na konci importu
Na konci se taky provede vymazání celé tabulky "import"
Protože se s tabulkou import nebude pracovat stylem seřaď, filtruj, hledej, apod. stačí mít dva sloupce:

ID (INT), PRODUCT (TEXT)
v ID autoincrement, v PRODUCT prostě kompletní řádek z CSV

Otázkou je, zda to stejné vytvořit pro export, všeobecně čtení je jednodušší a rychlejší.

Možná by ještě bylo zajímavý přidat do tabulky "import" sloupec USER ID pro případ, kdyby LOCK TABLE nějak selhalo - v případě importu dvou uživatelů (teoreticky, ale velmi nepravděpodbné) by se operace dokončila pouze s daty od posledního uživatele (nebo spíš lépe řečeno - dvě CSV od různých uživatelů by měly menší šanci se promíchat)

Ještě bych tam dal sloupec s pořadovým číslem řádku, pro možnost vypsání chybového hlášení s konkrétním řádkem.