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:
válasza:Hiába pontoztok le. Varchat akkor is rossz. Nvarchar jobb. Csinálj egy adatbázist legyen az Mysql vagy Mssql vagy odb. Csinálj egy lekérdezést C#, Java vagy akár C++ba de mehet phpba is. Legyen egy 1000 rekord a táblába és nézd meg mennyi a lekérdezési idő. Megfogsz lepődni. A fejlesztők is nvarchar-t ajánlanak, mind mysql mind microsoftnál, mind oraclelnél. De ti tudjátok
Biztos okosabbak vagytok
válasza:Szerintem itt csak a 8/10-es válaszoló értette meg mi a feladat, pedig ez nem egy valami bonyolult vagy egzotikus adatmodell. És nem, nincs vele semmi gond, száz ilyet láttam már nagy rendszerekben, semmi gond vele.
#12-es, arra van valami forrásod, hogy Oracle-ben lassabb a VARCHAR2? (A többihez nem értek.)
Kérdezőnek: ha VARCHAR-ban tárolod egy adott rögzített ábárázolás szerint a számokat az működhet, de van veszélye. Ha valamilyen numerikus valuera akarsz szűrni számszerűleg (eg. where to_number(products_properties.value)>3) exception-t fog dobni azoknál a rekordoknál amikben nem szám van. RDBMS-tl függően ez még akkor is probléma lehet ha leszűröd az adott property_id-ra is.
Egy jobb megoldás, ha products_properties táblában felveszel egy-egy oszlopot minden lehetséges adattípushoz, aztán lekérdezésnél vagy ki-NVL-ezed, hogy melyik nem NULL, vagy (ez az elegánsabb,) hozzáadsz egy data_type oszlopot a properties táblához, és az alapján DECODE-olod. (Illetve asszem mysql-ben COALESCE-nek és IF-nek hívják ezeket.)
Tehát ilyesmire gondolok:
products tábla:
id, name
1, Monitor
2, RAM
properties tábla:
id, name
1, Felbontás
2, Méret (col)
3, Memória
4, NVIDIA G-SYNC
products_properties tábla:
product_id, property_id, value
1, 1, '1920x1080'
1, 2, 27
1, 4, false
2, 3, '8192MB'
A products_properties táblában a value kapott stringet is, integert is és booleant is és a value típusára lennék kíváncsi, hogy milyen típust kapjon, vagy más megoldás ha van esetleg ahol a value ténylegesen azt a típust kapja amilyen értékeket fog kapni.
Szerintem a jelenlegi céges táblától bármi jobb csak ha már újra kell írni akkor a legjobb megoldást keresném meg erre.
A mostani products_properties tábla: [link]
válasza: válasza:#14: Köszönöm, így már érthető mi a probléma.
A javaslatom az, hogy a products_properties tábla legyen egy kapcsolótábla, ahol csak a property értékét tárolod el.
A value lehet valamilyen szöveges típus, amit fentebb ajánlottak.
És legyen még egy kapcsolótábla, amivel összerendeled a product-ot és a hozzá kapcsolódó propertiest.
Tehát ezek lennének a táblák (néhányat átneveztem logikai okokból, de remélem, hogy érthető a lényeg):
products(id, name)
properties(id, name)
properties_values(property_id, value)
products_properties(product_id, property_id)
Így nem lesz redundancia probléma az eredeti products_properties táblában és az adatbázis-szerkezet is bővíthető marad utólag, ha bejönne pl. egy új termékkategória.
válasza: válasza: válasza:Kapcsolódó kérdések:
Minden jog fenntartva © 2024, 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!