Dotaz: Verzované záznamy v MySQL

[Josef Kufner]

Ahoj!

Mám seznam nějakých věcí v tabulce Věc a číselník hodnot nějaké vlastnosti v tabulce Materiál. V tabulce Věc je sloupec s ID řádku v tabulce Materiál -- jde tedy o klasickou vazbu 1:N.

Problém je následující: Potřebuju, aby když upravím záznam v tabulce Materiál, aby se změna neprojevila u žádné Věci.

Tedy např. když si usmyslím, že dřevěné věci chci dřevěnější, aby se to projevilo jen u nově upravovaných/vytvářených věcí a věchny ostatní si ponechaly svoji původní dřevěnost.

To je ještě celkem jednoduché, ale zajímavé to začíná být s druhým požadavkem:

Mám ještě tabulku Barva, To je také číselník stejně jako Materiál a definuje různé barvy k různým materiálům. Vazba je také 1:N a říká, jaký materiál může mít jaké barvy.

Každý záznam v tabulce Věc má tedy dvě ID: jedno do tabulky Materiál a drué do tabulky Barva. Ať změním cokoliv v tabulce Materiál a/nebo Barva, tak se to nesmí projevit na žádném záznamu v tabulce Věc.

Máte nějaký nápad, jak to udělat?

Odpovědi

[cronin]

Pri dotazoch o existujúcej databázovej schéme je vždy dobré uviesť príslušné CREATE TABLE príkazy. Takto je to značne zmätočné. S tou väzbou 1:N je to nejaké dopletené; ak by sa jednalo o väzbu 1:N medzi tabuľkou Vec a Materiál, mal by byť v tabuľke Materiál stĺpec s foreign key odkazujúci na ID záznamu v tabuľke Vec. Tak by bolo možné pre jednu Vec špecifikovať N materiálov.

Ty však píšeš, že v tabuľke Vec je stĺpec s foreign key obsahujúci ID záznamu v tabuľke Materiál. Teda usudzujem, že tabuľka Materiál nie je nič viac ako zoznam známych materiálov a každá Vec môže byť práve z jedného Materiálu. Ak potrebuješ pridať nový Materiál, stačí pridať Drevenejšie Drevo do tabuľky Materiál a pri všetkých nasledujúcich Drevenejšie Drevených Veciach používať ID tohto nového záznamu. Detto pre farbu.

S tou farbou je to ale ešte zamotanejšie: Na jednej strane píšeš, že Farba je vlastnosť Materiálu, ale na druhej strane píšeš, že na Farbu sa odkazuješ s tabuľky Vec, nie s tabuľky Materiál.

Čo pravdepodobne potrebuješ, je pridať "indajrektnosť", napr.: Tabuľka Farba by mohla obsahovať zoznam známych farieb (biela, modrá, červená). Tabuľka Surovina by mohla obsahovať zoznam známych látok (drevo, papier, kov). Tabuľka Materiál by mohla obsahovať definíciu konečných materiálov vzniknuvších kombináciou Farby a Suroviny (Eben - cierna + drevo, Hliník - biela + kov). No a nakoniec tabuľka Vec by odkazovala na položku v mapovacej tabuľke Materiál. Pridanie novej Farby, Suroviny, Materiálu či Veci by znamenalo INSERT do príslušnej tabuľky a neovplyvnilo by to žiadne existujúce položky, len by to to rozšírilo množinu hodnôt, ktoré sú použiteľné v ostatných tabuľkách.

Zmätenie môže vyvolať to, že väzby v relačnej databáze fungujú presne opačne ako v objektovom programe. Zatiaľ čo v objektovom programe zložitý objek obsahuje odkazy na svoje komponenty a komponenty v princípe nevedia, súčasťou akého objektu sú, v relačnej databáze držia komponenty (slaves) väzby na nadradený (master) objekt.

Nakoniec už len dodám, že ešte som nemal rannú kávu, takže možno mám problém s kognitívnymi funkciami a dotaz som len prudko nepochopil.

[Josef Kufner]

Příloha:

• Diagram1.png (7552 bytů)

Ok, tak aby bylo jasné, jak to je myšleno, přikládám obrázek. Nevím jak se přesně ty šipky kreslí, ale snad to bude jasné (UML to být nemá, jen se mi hodil ten rámeček ).

[cronin]

Čím ďalej tým viac som presvedčený o tom, že proste ide o zle navrhnutú schému. Ako ale má vyzerat správne navrhnutá schéma nemožno povedať, kým nepoznáme biznis logiku vztahov medzi entitami, ktoré má opisovat.

[Josef Kufner]

Kdyby byla navrhnutá dobře, tak tu tento dotaz není

[cronin]

Aha, takže si si toho vedomý. To je fajn. Akurát, že Ti to asi nepomôže. Urobiť migráciu schémy asi nie je to, čo by potreboval, však?

[Josef Kufner]

Jakou migraci? Vždyť to ještě ani nefunguje...

[cronin]

Ono je to vo vyvoji? A co Ti teda brani navrhnut inu schemu, ktora bude vyhovovat potrebam?

[Ash]

Nevím nic o takovémto verzování, i když je mi jasné že jsou systémy které něco takového potřebují. Šlo by to řešit složitě že by se všude dávalo "od kdy do kdy" platí že dřevo=masivdřevo, a od kdy do kdy dřevo=překližka, a podle data uvdedného u věci by se vybral ten správný materiál, ale osobně bych prostě tabulku materiálů stále rozšiřoval o nové a nové materiály (suprdřevo, extradřevo, dřevo2000, dřevo3000+, s tím že identifikace nemusí být v názvu pokud nechcete, může tam být další sloupec třeba identifikátor verze dřeva (to už se blíží verzování) ovšem v tabulce věc pak musíte mít jako klíč jednak "název" materiálu, ale i verzi (a nebo to dělat přes id). V tabulce meteriál/barva tedy nesmíte !!! nic měnit, protože tím přicházíte o korektní historii a zákazníkovi pošlete blbej odstín červené jen proto, že si u vás koupil auto loni kdy byla in míň červená než letošní červená++. Brání vám tedy něco v tom, že nebudete měnit to, co se měnit z logiky věci nemá (barva již prodaných věcí atd.) a místo toho budete přidávat novinky (letošní odstín červené)? Podle mne je to korektní. Pokud to má nějaký frontend tak se při vkládání mohou nabízet jen poslední "aktuální" verze meteriálů a barev, případně se to ošéfuje nějakými db funkcemi.

[Michal Kubeček]

Podobný problém obvykle řeším tak, že místo jedné tabulky zavedu dvě, např.

create table TEAM_IDENTITIES(
  ID integer primary key,
  CREATED timestamp default CURRENT_TIMESTAMP,
  FINISHED timestamp,
  LAST integer
);

create table TEAMS(
  ID integer primary key,
  IDENTITY integer not null references TEAM_IDENTITIES(ID),
  CREATED timestamp default CURRENT_TIMESTAMP,
  FINISHED timestamp,
  NAME varchar(32) collate cs_CZ,
  ...
);

alter table TEAM_IDENTITIES
  add foreign key LAST references TEAMS(ID);

Změna údajů o družstvu se provede tak, že se vytvoří nový záznam v tabulce TEAMS, ukončí se platnost toho předchozího a aktualizuje se sloupec LAST příslušného záznamu v TEAM_IDENTITIES. Odkazy na družstvo, např. informace o domácím a hostujícím družstvu, ukazují do tabulky TEAMS, takže i když se změní název družstva, u utkání která hrálo pod starým, se bude pořád zobrazovat ten původní.

[Josef Kufner]

Díky. Sice jsem nejdříve uvažoval nad nějakým způsobem, jak to nacpat do jedné tabulky, ale nakonec jsem to udělal přesně takle. Ukázalo se to jako příjemě jednoduché a hezky to obchází problémy s updatem a selectem nad stejnou tabulku.