ugrás a tartalomhoz

Adatbázis tervezés - Egy mező többféle adattípussal

foxmulder · 2008. Jan. 17. (Cs), 15.21
Sziasztok!

Tegyük fel, hogy egy ingatlanokat tartalmazó adatbázisból szeretnénk kiválasztani az igényeinknek leginkább megfelelőt. Kérdés: hogyan nézzen ki az adatbázis. Eddig jutottam:

I. fázis:
INGATLANOK (id, cím, tulajdonos, alapterület, szobák száma, tájolás, szintek száma, ...)
A probléma ezzel az, hogy az ingatlanról nyilvántartott adatok "félesége" korlátozott. Úgy szeretném, hogy lehessen később is tulajdonságokat adni az ingatlanokhoz, legalábbis azokhoz, amelyeket az új tulajdonság bevezetése után fogok nyilvántartásba venni (az is érdekes probléma, hogy megjelenjen-e az újonnan bevezetett tulajdonság a már eddig regisztrált ingatlanoknál, illetve végig kell-e menni "kézzel" a régebbi ingatlanokon és kitölteni az új tulajdonság értékét, ha azt fontosnak tartjuk. Erre a problémára van tippetek?) . Például fél év múlva rájövök, hogy sokan érdeklődnek a fürdőszobák száma, vagy a burkolatok jellege iránt. Ezért...

II. fázis:
INGATLANOK (id, cím, tulajdonos)
TULAJDONSÁGOK (id, név)
INGATLANOK <-> TULAJDONSÁGOK kapcsolótábla (ingatlan_id, tulajdonság_id, érték)
Ezzel meg az a gond, hogy a különböző tulajdonságokhoz különböző adattípusok tartoznak. Az alapterület értéke négyzetméter, a tájolás szöveges érték. Talán lehetne kódokat alkalmazni és szoftveresen átalakítani a megfelelő értékekre, de ezt buherálásnak érzem. Ezért...

III. fázis:
INGATLANOK (id, cím, tulajdonos)
SZÖVEG_TÍPUSÚ_TULAJDONSÁGOK (id, név)
SZÁM_TÍPUSÚ_TULAJDONSÁGOK (id, név)
...
INGATLANOK <-> SZÖVEG_TÍPUSÚ_TULAJDONSÁGOK kapcsolótábla (ingatlan_id, szöveg_típusú_tulajdonság_id, érték)
INGATLANOK <-> SZÁM_TÍPUSÚ_TULAJDONSÁGOK kapcsolótábla (ingatlan_id, szám_típusú_tulajdonság_id, érték)
...

Jó ez így, vagy Ti másképp csinálnátok?
‹ sql oszlopok összehasonlítása Mysql karakterkészlet probléma utf8 és java kliens esetén ›
 ■
1

Másképp csinálnánk :)

foxmulder · 2008. Jan. 18. (P), 13.42
IV. fázis:
INGATLANOK (id, cím, tulajdonos...)
TULAJDONSÁGOK (id, név)
INGATLANOK <-> TULAJDONSÁGOK kapcsolótábla (ingatlan_id, tulajdonság_id, érték_id)

ÉRTÉKEK (id)

SZÖVEGES_ÉRTÉKEK (id, érték, érték_id)
SZÁM_ÉRTÉKEK (id, érték, érték_id)
...

Az INGATLANOK_TULAJDONSÁGOK kapcsolótábla 1:N kapcsolatban áll az ÉRTÉKEK táblával, mert az INGATLANOK_TULAJDONSÁGOK egy rekordjához csak egyféle érték tartozhat, de egy ÉRTÉK több INGATLANOK_TULAJDONSÁGOK rekord értéke lehet.
Az ÉRTÉKEK tábla unáris egyed, azaz csak egy attribútuma van, az azonosítója.

A SZÖVEGES_ÉRTÉKEK, SZÁM_ÉRTÉKEK (és még tetszőleges adattípusokat tartalmazó további egyedek) az ÉRTÉK egyed specializációi. Ezen specializációk száma ugyan kötött, de újabb adattípusra jóval kisebb az esély, mint új tulajdonságra. Az INGATLANOK_TULAJDONSÁGOK és ÉRTÉKEK egyedek közötti 1:N viszony N:M is lehet, ekkor még egy kapcsolótábla kell, de ez nem érinti a lényeget.

Vélemény?
2

Mennyire érdemes szétbontani az adatbázis tábláit?

Ustak · 2008. Aug. 13. (Sze), 19.55
Sziasztok, tudom picit régi topic, és nem is nagyon sok válasz érkezett rá, mégis gondoltam kérdezek én is egy hasonlót...
Tehát egy menűsor létrehozása lenne a feladatom, mégpedig termékekből. Valahogy így nézne ki:

//Termékek
  //=>Tejtermékek
     //=>Sajtok
        //=>félszáraz sajtok
           //Gouda sajt
           //trappista sajt
        //=>Penészes sajtok
           //hm de finom penészes sajt
  //=>Hústermékek
        //=>Sertéshús
           //sertéskaraj
           //dagadó
       //=>Marhahús
           //Marhalábszár
           //Marhafelsál
 //=>Egyéb termékek
          //=>Egyéb termékek alkategóra I
             //Egyéb termékek végtermék
             //Egyéb termékek végtermék 2
Persze eme menűsort a felhasználó szeretné majd termékekkel feltölteni, ha mondjuk egy új túrót kreál akkor fel tudja vinni az adatbázisba egy bohókás kis formon keresztül.
Ami a kérdésem lenne, hogy ilyen esetben mennyire érdemes az adatbázist külön táblákra bontani? Ugye csinálhatnék egy termékek táblát, és azon belül a fenti mezőket, de ha jól gondolom, elég nagy redundancia lenne akkor ha 200 féle sajtnál az első mező (termek) nél 200 szor szerepel a "sajtok". Vagy almenűpontonként teljesen szedjem szét (tehát termékek tábla, tejtermekek, stb stb...) Milyen úton szoktatok ilyenkor elindulni? Az igazság az hogy láttam már olyat aki adatbázisokat tervez... :-)
Köszönöm az ötleteket előre is!
3

2 táblával: termékek és menü

Thom · 2008. Aug. 13. (Sze), 23.28
Én semmiképpen nem szedném szét a termékeket, azokat gondolom mind hasonló tulajdonságokkal (adatokkal, mint méret, ár..) lehet jellemezni. Tehát egy közös termékek tábla lenne.
A többszintű menü azonban külön táblába kívánkozik, mert az másféle adatokat tartalmaz. Akkor ide jöhetnek a többi menüpontok is, ha vannak ilyenek.
A két táblát pedig össze lehet kötni 1-1 összerendeléssel, vagy akár egy kapcsolótáblával is. Ha kapcsolótábla lesz, akkor egy termék akár több helyen is megjelenhet (pl. gyártó szerint és termék fajta szerint listázva)
Menüt adatbázisban csináltam már úgy, hogy egy sornak (menüpontnak) van a, b, c "menüszint azonosítója", amit 3 adatmezővel írtam le - de láttam már úgy is, hogy egy sorban (menüpontban) megadják a szintet (mélységét) és a befoglaló/szülő menüpont azonosítóját. A menüpontok mindkét esetben jól le vannak írva az adatbázisban, csak a megjelenítésük megy másképp.
4

Köszönöm ez nagy segítség

Ustak · 2008. Aug. 14. (Cs), 09.37
Köszönöm az ötleteket, elindulok akkor ezen a vonalon!
6

termék törzsadat+többi adat

Thom · 2008. Aug. 14. (Cs), 14.56
Még egy ötlet:
Azt a helyzetet, ha a többféle kategóriájú terméknek más-más adattípusa van (egyiknél megadom a színét, másiknál a méretet), megint le lehet kezelni.
Csinálsz egy termék törzsadat táblát - benne olyan adatokkat, amik minden termékben megvannak (neve, leírása, kép), a kategória-specifikus adatok meg mennek egy segédtáblába:
- segédtábla ID
- főtábla kapcsoló ID
- adat neve
- adat értéke
Így később rugalmasan vehetsz fel új adattípusokat az egyes termékekhez. Sőt a módszert tovább fnomítva megadhatsz egy termékhez akár több (nagyker/kisker) árat is és mindenki azt látja, amit a jogosultsága megenged neki.
A termék főtáblát és a segédtáblát egy-több összerendeléssel kérdezheted le.
7

köszönöm

Ustak · 2008. Aug. 14. (Cs), 19.43
Igen, ez ravasz ötlet, köszönöm szépen, ha kész vagyok vele, ígérem megmutatom mire jutottam :-)
5

Fícsörök

janoszen · 2008. Aug. 14. (Cs), 10.06
A nagyon tuti megoldás az, hogy fölveszel egy numberic_features táblát, abba teszed a szám-jellegű paramétereket, stb. az egész kócerájt egy közös táblában kapcsolod össze. Ez lenne a normalizált forma. Namost, egy bizonyos mezőszám fölött ezt pl MySQL-lel nem tudod megcsinálni, mert maximum asszem 62 joint tudsz egy queryben csinálni, ergó denormalizálni kell, avagy összehúzni dolgokat egy táblába.