Autor Zpráva
ZdenekPNJ
Profil
Ř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
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
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
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
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.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: