dotNETportal.cz

Při návrhu databáze pro skladovou aplikaci, použitelnou na vrakovišti, jsem narazil na poměrně nečekaný problém a nemůžu s ním hnout.

Jde o to, že mám na skladě součástky, které obsahují další součástky a můžu prodat buď celek, nebo jednotlivé komponenty.

Původní návrh byl postaven na hierarchické struktuře. Čili např:

id | nazev | je_soucast (cizi klic)

-----------------------

1 | dvere | null

2 | sklo | 1

3 | klika | 1

4 | lanko | 1

Fungovalo to dobře, pokud jsem prodal dveře - pak se dvere odebraly z DB a kaskadove se umazaly i všechny součásti.

Horší je, pokud někdo chce třeba jen kliku. V tu chvíli mi ze skladu mizí klika, ale já bych potřeboval, aby zmizely i dveře - už nemám komplet dveře, jen části. Napadlo mě přidat trigger, který by po smazání "potomka" (kliky) smazal i "rodiče" (dveře). Jenže v tu chvíli by to kaskádově smazalo i zbylé 2 komponenty (sklo a lanko), ale to já nechci. U nich bych jen potřeboval odstranit tu závislost na dveřích. Uff.

Jde tohle ještě vůbec uhlídat na úrovni databáze?

Díky za jakýkoliv názor...

Nastavte akci při smazání na ON DELETE SET NULL. A při smazání se nezruší potomek.

Druhou lepší metodou je ještě před mazáním přeorganizovat strukturu. Jinak to neuděláte, databáze nepozná co chcete mazat a co ne :)

Pravda, ON DELETE SET NULL mi pomohlo s druhou částí problému (tj. prodám část dveří, smažu dveře, zbylé komponenty se nastaví na NULL - čili již nejsou součástí dveří, ale samostatné komponenty).

Teď zase nefunguje ta první část. Ale je to logické, přesně jak říkáte - databáze bohužel nepozná, co kdy chci jak smazat. Chtělo by to nějaký AI/mindread plugin :)

No, půjdu vymýšlet nějakou lepší strukturu. Upřímně řečeno jsem myslel, že to bude problem na jedno odpoledne, a přitom už se s tím mořím druhý den.

To jsem řešil. Postup byl takový, že klika nešla prodat, pokud byla součástí dveří. Tzn. je třeba vytvořit T-SQL ekvivalent činnosti "rozeber celek na součásti". Následně NEMÁTE celek (o ten se poníží sklad), ale MÁTE součásti. Pravda je nicméně taková, že by se to asi líp řešilo v business logice než v triggeru, ale v databázi by to mělo jít taky.