Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: adam999 29. 11. 2019, 20:49:08
-
Ahojte, akou vazbou by ste riesili kardinalitu medzi tabulkami v odlisnych schemach ktore pouzivaju pre ID datovy typ UUID.
Mame schemu pre nahrate obrazky na webe, kde je pre tento dotaz hlavna tabulka picture.
V dalsich schemach existuju tabulky, ktorych zaznamy maju kardinalitu s obrazkami M:N -> Kazdy zaznam z tychto tabuliek moze mat niekolko obrazkov, ale existujuci obrazok v tabulke picture moze byt pouzivany vo viacerych inych kontextoch.
Otazka teda znie, ci je podla vas lepsie spravit vazobnu tabulku v picture scheme, kde bude stlpec s id obrazka, a id entity (pripominam ze id su typu UUID takze kazde id je unikatne), alebo by ste v kazdej zo schem vytvorili k danej tabulke vazobnu tabulku s id obrazka? Takze by boli v X schemach tabulky (foo_id, picture_id), (bar_id, picture_id), atd. Dakujem.
-
V každém schématu samostatnou vazební tabulku.
Obrázky bych navíc vykopal z databáze do filesystému nebo ještě lépe do cloudu.
Edit: Místo UUID používám hash obrázku. Odstraní se tím duplicity.
-
V každém schématu samostatnou vazební tabulku.
Obrázky bych navíc vykopal z databáze do filesystému nebo ještě lépe do cloudu.
obrazky samozrejme su na filesysteme, tabulka obsahuje len info o obrazkoch, ako cestu atd.
-
IMHO záleží, jak jsou ta schémata koncipovaná, co které obsahuje. Technicky je možné oboje. Jedna vazební tabulka se dá použít pro M:N vazbu různých entit (i když to asi není z hlediska SQL nejčistší řešení). Viz třeba Discriminator v Hibernate nebo Polymorphic associations v ActiveJDBC (jde sice o odkazy na ORM, ale mimo jiné ukazují praxi).
-
IMHO záleží, jak jsou ta schémata koncipovaná, co které obsahuje. Technicky je možné oboje. Jedna vazební tabulka se dá použít pro M:N vazbu různých entit (i když to asi není z hlediska SQL nejčistší řešení). Viz třeba Discriminator v Hibernate nebo Polymorphic associations v ActiveJDBC (jde sice o odkazy na ORM, ale mimo jiné ukazují praxi).
Teda já nevím, ale jak chceš řešit cizí klíče, když ti jednou vazební tabulka bude ukazovat do Foo, a na jiném řádku do Boo?
-
IMHO záleží, jak jsou ta schémata koncipovaná, co které obsahuje. Technicky je možné oboje. Jedna vazební tabulka se dá použít pro M:N vazbu různých entit (i když to asi není z hlediska SQL nejčistší řešení). Viz třeba Discriminator v Hibernate nebo Polymorphic associations v ActiveJDBC (jde sice o odkazy na ORM, ale mimo jiné ukazují praxi).
Teda já nevím, ale jak chceš řešit cizí klíče, když ti jednou vazební tabulka bude ukazovat do Foo, a na jiném řádku do Boo?
Je to vybočení z SQL konceptu, ale integrita se dá zajistit třeba triggerem. Typ je prostě veden ve sloupci. Někdy se to IMHO hodí, jak ukazují i ty odkazy na ActiveJDBC a Hibernate. Vše co tvrdím je, že je to možno zvážit jako variantu s ohledem na okolnosti.
-
IMHO záleží, jak jsou ta schémata koncipovaná, co které obsahuje. Technicky je možné oboje. Jedna vazební tabulka se dá použít pro M:N vazbu různých entit (i když to asi není z hlediska SQL nejčistší řešení). Viz třeba Discriminator v Hibernate nebo Polymorphic associations v ActiveJDBC (jde sice o odkazy na ORM, ale mimo jiné ukazují praxi).
Teda já nevím, ale jak chceš řešit cizí klíče, když ti jednou vazební tabulka bude ukazovat do Foo, a na jiném řádku do Boo?
Je to vybočení z SQL konceptu, ale integrita se dá zajistit třeba triggerem. Typ je prostě veden ve sloupci. Někdy se to IMHO hodí, jak ukazují i ty odkazy na ActiveJDBC a Hibernate. Vše co tvrdím je, že je to možno zvážit jako variantu s ohledem na okolnosti.
V pořádku. Já tě za to nelynčuju.
Přiznejme si, že takto je to ale dost teoretický. Napadá tě nějaký ideální příklad? (Z toho, co zadal tazatel nejsem moc moudrej. Přišlo mi, že mu vadí "jen" ty hranice napříč schematu.)
-
Prosim nerieste tu integritu, triggery ani nic podobne :) otazka bola len aky je podla vas spravny navrh tabuliek. Vazobna tabulka v scheme picture kde bude id obrazka, a uuid akejkolvek inej entity (vdaka uuid) alebo schema picture bude obsahovat len zadefinovane obrazky, a to k comu sa viazu sa bude riesit v kazdej scheme zvlast, teda foo schema bude mat tabulku s foo_id a picture_id, bar schema bude mat tabulku s bar_id a picture_id a pod.
-
Prosim nerieste tu integritu, triggery ani nic podobne :) otazka bola len aky je podla vas spravny navrh tabuliek. Vazobna tabulka v scheme picture kde bude id obrazka, a uuid akejkolvek inej entity (vdaka uuid) alebo schema picture bude obsahovat len zadefinovane obrazky, a to k comu sa viazu sa bude riesit v kazdej scheme zvlast, teda foo schema bude mat tabulku s foo_id a picture_id, bar schema bude mat tabulku s bar_id a picture_id a pod.
Máš tabulku foo, která vazbí N obrázků z tabulky picture. Pak máš tabulku boo, která vazbí N obrázků z tabulky picture. Tak?
V takovém případě bych měl pro každý extra vazební tabulku.
foo -> foo2picture -> picture
boo -> foo2picture -> picture
-
Prosim nerieste tu integritu, triggery ani nic podobne :) otazka bola len aky je podla vas spravny navrh tabuliek. Vazobna tabulka v scheme picture kde bude id obrazka, a uuid akejkolvek inej entity (vdaka uuid) alebo schema picture bude obsahovat len zadefinovane obrazky, a to k comu sa viazu sa bude riesit v kazdej scheme zvlast, teda foo schema bude mat tabulku s foo_id a picture_id, bar schema bude mat tabulku s bar_id a picture_id a pod.
Máš tabulku foo, která vazbí N obrázků z tabulky picture. Pak máš tabulku boo, která vazbí N obrázků z tabulky picture. Tak?
V takovém případě bych měl pro každý extra vazební tabulku.
foo -> foo2picture -> picture
boo -> foo2picture -> picture
Dakujem
-
Prosim nerieste tu integritu, triggery ani nic podobne :) otazka bola len aky je podla vas spravny navrh tabuliek. Vazobna tabulka v scheme picture kde bude id obrazka, a uuid akejkolvek inej entity (vdaka uuid) alebo schema picture bude obsahovat len zadefinovane obrazky, a to k comu sa viazu sa bude riesit v kazdej scheme zvlast, teda foo schema bude mat tabulku s foo_id a picture_id, bar schema bude mat tabulku s bar_id a picture_id a pod.
Máš tabulku foo, která vazbí N obrázků z tabulky picture. Pak máš tabulku boo, která vazbí N obrázků z tabulky picture. Tak?
V takovém případě bych měl pro každý extra vazební tabulku.
foo -> foo2picture -> picture
boo -> foo2picture -> picture
Dakujem
IMHO to mělo být
foo -> foo2picture -> picture
boo -> boo2picture -> picture
Moje alternativa byla přidat do vazební tabulky sloupec s typem, podle kterého se hledá boo nebo foo, takže lze přes jednu vazební tabulku vázat různé typy, je to ale specifické nestandardní řešení, které se hodí jen někdy:
foo -> picture_assignements(type = foo) -> picture
boo -> picture_assignements(type = boo) -> picture
Ale s ohledem na způsob dotazu a reakcí tazatele bych doporučil se držet standardního postupu, tj. první varianty.
-
Pokud by bylo třeba listovat všechny "závislosti obrázků", tak by šlo v postgresql použít inherited tables.https://www.postgresql.org/docs/10/tutorial-inheritance.htmlBboo2pictures (https://www.postgresql.org/docs/10/tutorial-inheritance.htmlBboo2pictures) a foo2pictures zdědit od jedné tabulky, FK dát až na děti (a popř. triggerem zakázat vkládání do rodiče).To vlastně spojuje výhody obou řešení: umožní to řešit referenční integritu klasicky, mít klasické oddělené tabulky bez řešení typu, a zároveň mít možnost vypsat všechny výskyty obrázku.
Ale tato možnost je specifická pro postgres a navíc to vypadá, že je stranou zájmu vývojářů (některé věci tam nejsou dořešené, byť to pro daný usecase nevadí, tak je otázka, jestli tudle funkcionalitu někdy nevyřadí), takže takto bych to dělal, jen pokud bych pro to měl opravdu důvod, není to "řešení první volby".
-
Prosim nerieste tu integritu, ...
Chápu tu poznámku, ale jen bych rád zdůraznil, že integrita je klíčová vlastnost, proč používat databázi :-) Takže říct: "to neřešte" je... :-)
IMHO to mělo být
foo -> foo2picture -> picture
boo -> boo2picture -> picture
Samozřejmě. Pardon!
Pokud by bylo třeba listovat všechny "závislosti obrázků", tak
Oni jsou tam boje mezi těmi, kteří by rádi postgre více objektovej, a mezi těmi, kteří "takové blbost sem netahejte". (Jsem v druhém táboře :-) )
Osobně bych to řešil manuálně pomocí view. V Postgre je to bez výkonnostní ceny.
-
Prosim nerieste tu integritu, ...
Chápu tu poznámku, ale jen bych rád zdůraznil, že integrita je klíčová vlastnost, proč používat databázi :-) Takže říct: "to neřešte" je... :-)
IMHO to mělo být
foo -> foo2picture -> picture
boo -> boo2picture -> picture
Samozřejmě. Pardon!
Pokud by bylo třeba listovat všechny "závislosti obrázků", tak
Oni jsou tam boje mezi těmi, kteří by rádi postgre více objektovej, a mezi těmi, kteří "takové blbost sem netahejte". (Jsem v druhém táboře :-) )
Osobně bych to řešil manuálně pomocí view. V Postgre je to bez výkonnostní ceny.
Chápu to dobře, že byste měl nad jednou tabulku více view pro foo, boo atd?
-
Pokud by bylo třeba listovat všechny "závislosti obrázků", tak by šlo v postgresql použít inherited tables (...)
Ale tato možnost je specifická pro postgres a navíc to vypadá, že je stranou zájmu vývojářů (některé věci tam nejsou dořešené, byť to pro daný usecase nevadí, tak je otázka, jestli tudle funkcionalitu někdy nevyřadí), takže takto bych to dělal, jen pokud bych pro to měl opravdu důvod, není to "řešení první volby".
Aha, to je poměrně zajímavá možnost. Otázka zní, za je pro to podpora třeba v nějakých ORM (pro případ, že by se nepoužívalo čisté SQL)? Pro mě by bylo totiž hlavní motivací odstranit nutnost mít pro každý foo, boo zvlášť mapování a biolerplate kód navíc.
-
Chápu to dobře, že byste měl nad jednou tabulku více view pro foo, boo atd?
Vyzházel jsem ze zadání:
takže lze přes jednu vazební tabulku vázat různé typy,
Pokud by bylo třeba listovat všechny "závislosti obrázků", tak
Takže místo toho, abych měl objekt, předka, ze kterého by se odvodila vazební tabulka; tak bych to udělal naopak. V případě potřeby, kdy chci sloučit všechny "závislosti obrázků", tak si vytvořím jeden view, ve kterém dám unionem všechny ty vazební tabulky. Například.