Pár elemes listák
Sziasztok!
Problémám a következő. Vannak egy csomó ~30 elemű listánk, aminek az értékeit aztán tároljuk különböző rekordokban (ott nyilván integerként).
Néha exportálgatunk, ott nem árt ha olvashatóan szerepelnek a dolgok, és néha szeretjük, ha az exportot kiköpi az adatbáziskezelő.
Mi a legoptimálisabb megoldás?
I.
Minden listának külön tábla?
pro
-idegen kulcsok szépen működnek
-minden szép és jó
kontra
-nem overkill?
-a sok hülye tábla, amik között nem találjuk meg a tényleg használt táblákat.
II.
Csinálunk lista_csoport és lista_elem táblákat
#lista_csoport#
-idcsoport (pk)
-csoport (varchar)
#lista_elem#
-idelem (pk)
-idcsoport (fk)
-elem
És az idelem értékeket tároljuk ahol kell.
pro
-kevés tábla
-külső kulcsok részben működnek
kontra
-különböző csoportok pk-i keverednek, a kulcs nem hordoz az ember számára semmiféle értelmezhető információt (ez azért néha nem rossz). esetleg szorozzuk meg a csoport azonosítót százzal és ebben az intervallumban tároljuk a lista elemeit (ez ám a gány, de talán nem is olyan hülyeség)
-olyan kulcs is kerülhet adott helyre, aminek ott semmi értelme (egy totál másik csoporthoz tartozik) (mondjuk ha a csoport azonosító benne van az elem kulcsban, akkor akár lehet rajta egy könnyen megírható trigger)
III.
lista_elembe felveszünk még egy mezőt, ami az adott érték indexét tárolja, de ez még nagyobb butaság, mert vagy két mező lehetne idegen kulcs, vagy nem tudná kezelni az idegen kulcsokat az adatbázis (azért nem baj, hogy nem tudok berakni olyant ami nem létezik)
----------
Csak SQL segítségével lehet ezt normálisan kezelni, vagy van valami értelmes megoldás erre a problémára?
■ Problémám a következő. Vannak egy csomó ~30 elemű listánk, aminek az értékeit aztán tároljuk különböző rekordokban (ott nyilván integerként).
Néha exportálgatunk, ott nem árt ha olvashatóan szerepelnek a dolgok, és néha szeretjük, ha az exportot kiköpi az adatbáziskezelő.
Mi a legoptimálisabb megoldás?
I.
Minden listának külön tábla?
pro
-idegen kulcsok szépen működnek
-minden szép és jó
kontra
-nem overkill?
-a sok hülye tábla, amik között nem találjuk meg a tényleg használt táblákat.
II.
Csinálunk lista_csoport és lista_elem táblákat
#lista_csoport#
-idcsoport (pk)
-csoport (varchar)
#lista_elem#
-idelem (pk)
-idcsoport (fk)
-elem
És az idelem értékeket tároljuk ahol kell.
pro
-kevés tábla
-külső kulcsok részben működnek
kontra
-különböző csoportok pk-i keverednek, a kulcs nem hordoz az ember számára semmiféle értelmezhető információt (ez azért néha nem rossz). esetleg szorozzuk meg a csoport azonosítót százzal és ebben az intervallumban tároljuk a lista elemeit (ez ám a gány, de talán nem is olyan hülyeség)
-olyan kulcs is kerülhet adott helyre, aminek ott semmi értelme (egy totál másik csoporthoz tartozik) (mondjuk ha a csoport azonosító benne van az elem kulcsban, akkor akár lehet rajta egy könnyen megírható trigger)
III.
lista_elembe felveszünk még egy mezőt, ami az adott érték indexét tárolja, de ez még nagyobb butaság, mert vagy két mező lehetne idegen kulcs, vagy nem tudná kezelni az idegen kulcsokat az adatbázis (azért nem baj, hogy nem tudok berakni olyant ami nem létezik)
----------
Csak SQL segítségével lehet ezt normálisan kezelni, vagy van valami értelmes megoldás erre a problémára?
Félálomban, tudatlanul: egy
nem jó
Szerintem ez RDBMS függő
De nem is értem a problémádat:
Listák tábla
csoport id integer,
lista id integer,
egyéb adatok ...
Ha erre kell hivatkoznod, akkor természetesen a hivatkozó táblában meg kell adni a "csoport id"-t is, de ha külön táblát készítesz minden csoportnak, akkor még macerásabb a helyzet.
Ha meg ebből a táblából akarsz kifelé hivatkozni, akkor max. olyan megkötést tudok elképzelni, hogy akire hivatkozol, abban legyen PK a hivatkozott adat.
Szóval nem tiszta, de lehet, hogy bennem van a hiba.