Idea Phoca Cart

Jinak pokud by bylo ID před dvojtečkou, tak nějaký spec. znak není přece třeba řešit. Prostě by se za ID považovala všechny číslice 0-9 před první dvojtečkou.

Souhlas, formát: 1:Jméno bude asi nejlepší, jak píšeš, s kontrolou INT před dvojtečkou. Jméno bez čísla, to by byl masakr pro databázi, hledat v každém řádku jméno kategorie,navíc v utf-8. Ono s těma ID to bude samozřejmě komplikovanější, např. ID produktu, příklad import.

Importuje se řádek, který obsahuje ID 23, ale takový už existuje v databázi, co teď:

- vymazat ten v databázi
- nemazat ho
- pouze updatovat (v podstatě znamená vymazat ten v databázi)
- nebo ignorovat ID a posunout produkt na další ID (protože ID je autoincrement)

Tady se asi parametru "Přepsat existující produkt při importu" (ANO/NE) nevyhnu. No a samozřejmě pokud taková možnost bude, pak se zase dostáváme k tomu, že se nebude moct použít následující varianta č.1:

Možnosti při importu dat:

varianta č.1) Při importu se smažou stávající data a nahradí se pomocí INSERT (hodně rychlá varianta, nenáročná na SQL dotaz, ale není to update)

varianta č.2) Při importu se kontrolují stávající data a nahrazují se pomocí INSERT ... ON DUPLICATE KEY UPDATE (vlož, pokud existuje ID, pouze udělaj update) - Problém ON DUPLICATE KEY UPDATE je, že se nedokáže provést v jednom SQL dotazu pro všechny vložné řádky a musí se opakovat ve foreach - což může být u více položek hodně problematický

A to nemluvím o kontrole vztahu ID vs. Jméno:

- ID neexistuje OK
- ID existuje - přepsat
- ID existuje ale jméno ve spojitosti s ID neexistuje - v databáz je 23:Jablko, a teď uživatel importuje 23:Hruška - co teď - je to nový produkt a prostě dáme jiné ID 26:Hruška, nebo uživatel změnil 23 z Jablka na Hrušku a není to nové ID, jen název je jiný ??? Tady už si taky nemusíme vystačit jen SQL, ale budeme muset kontrolovat i pomocí PHP a načítání jednotlivých řádků - což by taky mohlo databázi totálně zatížit

Identifikaci produktu bych při importu spíš než na ID pověsil na SKU. Opět ID nikomu nic moc neřekne, SKU je poměrně jasný identifikátor, každý ví co si má pod ním představit. No a pokud SKU existuje, tak hodnoty přepsat, protože když už bude mít někdo duplicitní SKU, tak je to jeho boj. Takže pokud pod SKU 123 místo Jabka nahrává Hrušku, tak přepsat.

Popř. by bylo hezký mít možnost importovat dle EAN.

Stávající data bych při importu nemazal, tím by se zase zavřela cesta pro nějaký zjednodušený import - typicky pouze aktualizace cen - tedy jednou za čas nahraji komplet sortiment s popisy apod. ale třeba každý týden přeceňuji a chci nahrát jen nové ceny.

S ON DUPLICATE KEY je ještě potíž v tom, že je to jen MySQL. Do budoucna tedy problémy s kompatibilitou s jiným SQL serverem (nevím tedy jestli s tím vůbec počítáš).

Problém je, že jediný ID je skutečně identifikátor. U produktů jsou sloupce EAN, SKU, ISBN a podobně a teoreticky by se dal přidat parametr pro výběr klíčového sloupce. Např. vyberu EAN a pokud bude EAN stejné, pak řádek jen updatuju. Tam by ale zase byl problém s S ON DUPLICATE KEY, který potřebuje mít daný sloupec jako klíč, aby se podle něj řídil - a dělat dynamicky změny ve struktuře databáze, to asi není vhodné řešení.

Vše optimalizuji pro MySQL / MariaDB, za cca 9 let jsem měl snad jen jednu otázku na podporu MSSQL, takže ostatní databáze jsem zatím neměl důvod řešit

H13 napsal: Problém je, že jediný ID je skutečně identifikátor.

Systémově třeba ano (i když u toho SKU by možná Unique index stál za zvážení), ale v praxi je obvykle SKU nebo EAN jedinečný. Pokud se SKU potká od dvou dodavatelů je naprosto běžným standartem, že si jej firmy upraví předponou tak aby jedinečné u nich v systému bylo.

EAN je také v drtivé většině případů jedinečný, i když u některého sortimentu se "točí" - zjistil jsem to např. u levných DVD, tam jeden EAN točili na několik různých titulů.

Ale je fakt, že jsem zapomněl že v MySQL je potřeba ten Unique index. Bez něj by to muselo být nejdřív dohledání a pak insert nebo update.

Teoreticky se dá dát klíč více sloupcům: primary key = id, key = ean, sku, ... Při "aplikaci" ON DUPLICATE KEY, když dostane řádek se stejným EAN a jiným SKU, prostě updatuje ten řádek s EAN, pokud se stejným SKU, pak zase updatuje řádek se SKU, pokud budou obě odlišné, pak vloží nový řádek.

Já si to teď testuju:
INSERT INTO products (title, ean, isbn, sku) VALUES ('xxx', 'yyy', 'zzz', 'aaa')
ON DUPLICATE KEY UPDATE title = VALUES (title), ean = VALUES (ean), isbn = VALUES (isbn), sku = VALUES(sku);

S tím, že se musí vypsat všechny sloupce pro duplicate (title= VALUES(title)). Otázkou je zda to nebude moc náročné (paměť, čas) :idea:

No ale aby fungovalo to ON DUPLICATE KEY tak musí být ty indexy Unique ne? To by znamenalo zásah do struktury databáze, trochu změna filozofie těchto sloupců. Ale pak by to fungovalo, to je pravda, jen nevím, jestli, když to pojede podle všech sloupců, by pak nedocházelo ke zmatení co se vlastně aktualizovalo a proč.

ON DUPLICATE KEY používám v jednom projektu v podstatě přesně k tomuto (i když tam je to pravda dle primárního klíče), a spuštění 1000 update je pod sekundu na běžném hostingu, nemám to přesně změřené, ale je to dost rychlé.