| Autor | Zpráva | ||
|---|---|---|---|
| ZdenekPNJ Profil |
#1 · Zasláno: 14. 10. 2015, 13:51:38
Řeším teď poměrně zásadní věc. Na webu mám články, novinky, obrazky, soubory, osoby a firmy. A potřeboval bych pomocí databáze sql udělat možnost tzv. SOUVISEJÍCÍHO PROPOJENÍ všech těchto položek.
Struktura sql: tabulka Článek (idc, titulek, další položky......) tabulka Novinka (idn, titulek, další položky.....) tabulka Obrázek (ido, titulek, další položky.....) tabulka Soubor (ids, titulek, další položky.....) tabulka Pracovník (idp, titulek, další položky.....) tabulka Firma (idf, titulek, další položky.....) a tabulka Propojení(jedinecne_id, clanek_id, novinka_id, obrazek_id, soubor_id, pracovnik_id, firma_id) Zde by se ukládalo následujícím způsobem - Příklad: propojení článek_id=11 a obrázek_id=22 ------>insert into Propojení values(null,11,0,12,0,0,0) propojení článek_id=11 a pracovník_id=33 ------>insert into Propojení values(null,11,0,0,0,33,0) propojení novinka_id=44 a pracovník_id=33 ------>insert into Propojení values(null,0,44,0,0,33,0) Jde mi nejen o logiku věci, ale i zpracování, které by co nejméně zatěžovalo databázi. Jistě, šlo by sice udělat zvlášť tabulky na každé možné propojení, ale to by těch tabulek bylo šíleně hodně. Takhle by bylo vše v jedné a při zoobrazení článku by se měl volat sql dotaz, který by zjistil, co všechno s článkem souvisí: SELECT * from Propojení where clanek_id=11 --------> Vypsalo by to všechny řádky, kde se nachází clanek_id číslo 11. Řešení a dotazy: A) Vždy jen 2 položky? - Podle mého by bylo nejlepší, kdyby se pro jeden řádek vždy párovali jen dvě položky. Ostatní by byly buď 0 a nebo '' prázdné množiny. B) Je lepší, kdyby prázdné položky byly 0 a nebo prázdné množiny ''? C) Jak zabránit možným duplicitám? Aby nebylo např. 2x a vícekrát stejné párování D) Jak co nejefektivněji takováto data vytahovat z databáze? Mockrát děkuji všem za nápady. |
||
| mimochodec Profil |
#2 · Zasláno: 14. 10. 2015, 14:59:11
ZdenekPNJ:
„Jde mi nejen o logiku věci, ale i zpracování, které by co nejméně zatěžovalo databázi.“ Logika věci velí pro každou z těch vazeb mít extra tabulku. V nějakých speciálních případech daných aplikační architekturou by jedna společná tabulka nemusla být nevýhodou, ale snažíš se použít čtverec tam, kde všichni používají kolo. Fungovalo by to, ale přínos oproti více vazebním tabulkám by nebyl žádný. |
||
| juriad Profil |
#3 · Zasláno: 14. 10. 2015, 15:05:50
www.slideshare.net/billkarwin/sql-antipatterns-strike-back
Od slidu 32. Je tam několik návrhů, jak přidávat komentáře k různým typům objektů, ty se snažíš o něco podobného (jen na obě strany). |
||
| Dusann Profil |
#4 · Zasláno: 14. 10. 2015, 15:41:50
Ak je možné zmeniť štruktúru tvojej DB, tak by som jednoznačne vytvoril väzby medzi existujúcimi tabuľkami cez foreign keys.
Najprv si ale definuj aké vzťahy existujú medzi jednotlivými entitami v tvojej aplikácii - Článek, Novinka, Obrázek, atd... |
||
| ZdenekPNJ Profil |
#5 · Zasláno: 15. 10. 2015, 07:53:53
mimochodec:
To b sice možná šlo, ale mohlo by to védst až k mnoha deítkám tabulek viz. Články x Novinky Články x Obrázek Články x Soubor Články x Pracovník Články x Firma Novinky x Obrázek Novinky x Soubor atd................ a pokud by se přidala jedna nová položka (např. video) přibylo by dalších x tabulek. |
||
| mimochodec Profil |
ZdenekPNJ:
„To b sice možná šlo, ale mohlo by to védst až k mnoha deítkám tabulek“ To by bylo taky špatně. Namaluj si to na papír. Každý článek má autora. Každý autor patří do nějaké firmy. To ale neznamená, že bys potřeboval tabulku Články x Firma. K firmě se z článku dostaneš přes autora, tedy přes dvě vazby. A ještě dodám: tam, kde ta vazba je principielně jedna, vazební tabulku nepotřebuješ. Pokud třeba obrázek patří jednoznačně k jednomu článku, v tabulce obrázků uděláš sloupec IDclanku. Zásadní je mít jistotu, že těch vazeb obrázek-článek nebude nikdy víc, tedy že nebudeš nikdy chtít přiřazovat jeden obrázek víc článkům. A druhá zásadní věc je, jestli tu vazbu nebudeš chtít časem měnit a ty změny si pamatovat. U dvojice obrázek-článek to asi nehrozí, u dvojice pracovník-firma jednoznačně ano. |
||
|
Časová prodleva: 9 let
|
|||
0