Diskuze: správný navrh db
V předchozím kvízu, Online test znalostí SQL a databází, jsme si ověřili nabyté zkušenosti z kurzu.

Člen

Zobrazeno 8 zpráv z 8.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí SQL a databází, jsme si ověřili nabyté zkušenosti z kurzu.
Dalo by se to logovat zvlast do tabulky treba extra sql dotazem.
id, id_query, id_user, datum
id - radek logu
id_query - id sql dotazu, ktery byl nad zaznamem proveden
Pripadne tam dat jeste id_source, treba jakoze class_user dotaz provedla.
Ale ten zaznam o create by tam asi mel byt. To se deje jen jednou a muze to byt
dulezite.
Jo, a mozne nekdo jeste napise. Mam pocit, ze moderni db to nejak dovedou logovat sami.
Pokud potřebuješ evidovat, kdo konkrétní záznam "vytvořil" a "upravil",
tak je vcelku logické, že to bude v "těch" tabulkách u položek
(předpokládám, že tam máš pouze IDčka jako cizí klíč)...
Pokud ale potřebuješ evidovat i historii "upravovatelů" záznamu, budeš
muset mít extra tabulku (vazební), kde tyto změny budeš zapisovat.
Děkuji za odpovědi, ale asi jsem uvedl špatný příklad. Zkusím to ještě jednou i s diagramem na něčem lepším.
Mam tuto db, kde každá tabulka má diskuzi, ale tyto diskuze jsou na sobě
nezávislé.
Je lepší varianta takto udělat tabulku s nulovými cizími klíči, než
vytvářet tři tabulky tzn: DiskuzeProdukt, DsikuzeObjednavka .....
Dá se to takto udělat, ale ta diskuse se bude hůře "moderovat". Kdysi jsem to v jedné aplikaci udělal stejně a upřímně, nebylo to "ono". Sice jsem ukládání řešil jedním dotazem, ale byl dosti složitý (dost jsem se tenkrát natrápil, než to začalo fungovat podle mých představ) a při každé zamýšlené úpravě, či požadovaném vylepšení jsem musel důkladně promyslet, jaké dopady to bude mít na zobrazení v jednotlivých sekcích. Osobně bych radši volil extra tabulku ke každému druhu. Je to pohodlnější na správu, protože se nemusíš ohlížet na další "oblasti diskuse" a v každé diskusi můžeš mít i různá specifika.
Tezko rici. Pises, ze jsou nezavisle na sobe. Logicky tedy staci jedna tabulka.
diskuze: id_diskuze, id_typ, id_tab, zprava, datum
Mysleno tak, ze id_typ je nejake id_tabulky (1=produkt, 2=objednavka) a id_tab je id, ktere je v te tabulce.
SELECT sloupce FROM diskuze WHERE id_tabulka=1 AND id_tab=123
Pokud by to bylo ale zavisle, mohlo to byt propojene na vsechny 3, pak bych mel struturu, jak mas na obrazku
diskuze: id_diskuze, id_produkt, id_objednavka, id_faktura, zprava, datum
A jak pise Michal Štěpánek, urcite pouzitelne reseni je mit kazdou diskuzi
zvlast v tabulce. Pak tam nemusis delat to pomocne id_typ. Mozna, vuci db prave
o ten 1 sloupec uspornejsi. Coz je ale celkem zanedbatelna uspora
Jo, a idecka bych daval na zacatek tabulky, delsi data (a v horsim pripade s
promenou delkou), ktera nepouzivas ve WHERE az za to.
Takhle nejak vypada struktura tabulky, kde je id na zacatku. WHERE se dobere
vsech idecek do 12 kroku.
ooo-ooo-ooo-ooo-ruznadelka
ooo-ooo-ooo-ooo-ru
ooo-ooo-ooo-ooo-ruzna
Opak je o 10 kroku navic (v cyklu preskoc 0-n znaku)
ruznadelka-ooo-ooo-ooo-ooo
Ale je mozne, ze moderni db uz tento problem nemaji, ze si uz pri ukladani tabulku prizpusobi a jen uzivateli to ukazuji jinak. A nebo promenne texty ukladaji zvlast, odkazuji na ne ideckama.
Nejvíc se mi líbí ta varianta s id_typ a id_tab díky.
Zobrazeno 8 zpráv z 8.