MySQL-ban, hogy lehet azt megoldani ha egy mezőnek több értéke lehet?
Pl. van egy properties tábla benne a termék tulajdonságok neveivel és azonosítóival egy products táblában meg a termékek.
Ha egy termékre valamilyen tulajdonságot szeretnék rárakni akkor a products_properties táblában létrejön egy új rekord amiben benne van a property azonosítója, a termék azonosítója és végül maga az érték ami legyen 'value'.
Itt a 'value' milyen értéket kell kapjon ha abban lehet int, float, boolean és varchar?
Én úgy gondolom, hogy ebben az esetben varchar lenne a legjobb mert abban lehet az előző hármat is tárolni.
Van ettől jobb, másabb megoldás?
Még olyat találtam ahol minden érték típusnak létrehoznak egy külön táblát tehát lenne products_properties_text, products_properties_int, products_properties_boolean és products_properties_float ahol a 'value' mindig az adott tábla szerinti érték típust viseli.
És azt is olvastam, hogy ebben az esetben a MongoDB ajánlott inkább mert ott nincsenek előre definiált értékek.
válasza:Jézusom emberek...
#16-os: nem a property-nek van valueja, a property az annyi, hogy "felbontás" Adott termék adott propertyjének van valueja.
#18-as: he? Szerinted nem az RDBM-s való arra, hogy sok adatot tároljál? Helyette XML? Mi van?!
#20: ha több változatta van egy monitornak az több különböző termék (product.) Nincs SEMMI probléma ezzel az adatmodellel, nincs benne redundancia. Csak az volt a kérdés, hogyan tárolja a product_property-ben a value-t, aminek többféle adattípusa lehet.
válasza:Már hogy ne lenne benne redundancia!
Rögtön az első rekord példa rá:
1, 1, '1920x1080'
2 lehetőség van:
* Van 1000 azonos felbontású monitor, akkor 1000-szer beírja, hogy 1920x1080? Ez redundancia. Kerülendő.
* Nem írja be 1000-szer, hanem az összes monitor ezt az egy rekordot használja. Ez még rosszabb, mert frissítési anomáliákat okoz, emiatt szintén kerülendő. Anomália alatt pl. képzeljük el, hogy frissítjük ezt az egy rekordot és az mind az 1000 monitorra érvényesül, pedig lehet, hogy csak egynek volt hibásan megadva ez az adat.
válasza:"#16-os: nem a property-nek van valueja, a property az annyi, hogy "felbontás" Adott termék adott propertyjének van valueja."
Van a termék. Ennek van valamilyen property-je (pl. felbontás, szín). A property-nek van értéke (pl. 1920x1080/1920x1200/stb., fekete/fehér/stb.).
Ha a property-t és a terméket egyben kezeljük, akkor egy katyvasz, keveredés lesz belőle, ezért jobb, ha külön tároljuk a lehetséges property-ket és hozzárendeljük a termékhez. Ugyanezen okból jó, ha a property-hez rendeljük hozzá a lehetséges értékeket.
válasza:Ok, így már értem mire gondolsz, csak a példádban félrevezettek az oszlop nevek. A property_value PK-ját property_value_id-nak hívnám, és erre hivatkoznék a product_propertiesben.
Ez is amúgy csak az ilyen "lookup" típusú propertykre igaz, ahol egy előre definiált értéklistából kaphat értéket. Ha van pl. egy "súly" property-d, ott eltárolsz egy számot és kész. Ha van 5000 3 kilós terméked akkor lesz 5000 rekordod "3" valueval, nincs azzal semmi gond. Amúgy én a felbontást sem lookup listában tárolnám, hanem két külön number valueként (horizontális és vertikális felbontás.) Így könnyebb benne keresni (kisebb-nagyobb felbontás etc.)
válasza: válasza: válasza:Kapcsolódó kérdések:
Minden jog fenntartva © 2025, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!