- Rekordérdeklődés a Xiaomi hátsó kijelzője iránt
- Mobil flották
- Milyen okostelefont vegyek?
- Akciófigyelő: Komoly kedvezményekkel és ajándékokkal startol a Xiaomi 15T széria
- Xiaomi 15 - kicsi telefon nagy energiával
- Apple iPhone 17 - alap
- iPhone topik
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Fotók, videók mobillal
- Honor 400 Pro - Gép a képben
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz
Speeedfire #841 üzenetére
MINDENT id szerint azonosíts. Soak tanácsa szerintem nagyon rossz, hogy inkább mindent varcharral vagy texttel tárolj, kerülendő megoldás, mert nagyon sok partner közti keresésnél észrevehetően lassú lesz a szövegalapú keresgélés.
Az id-khoz tartozó neveket pedig külön tárold. Pl. legyen egy parameters tábla, abban pedig id | name vagy hasonló. De hogy továbbvigyük: gondolj bele, mi van, ha pl. ezeket a neveket fordítani is kell. Akkor még a fordításhoz tartozó "csomópontot" is id szerint érdemes inkább hozzákapcsolni, és a fordítást megint külön táblában tárolni. Tehát akkor meg id | translation_node_id felosztásban lehet. (persze beleerőltetheted azonos táblába az összes fordítást, úgy, hogy minden nyelvhez külön "oszlop" tartozik, de az sem egy túl szép megoldás, nem biztos, hogy mindenre van fordítás, és akkor ott addig NULL van)
Sok ilyen esetben érdemes inkább sok-sok logikailag különálló táblát külön is tárolni, a táblakapcsolások nem fogják nagyon lassítani a lekérdezéseidet, sőt, adott esetben sokkal gyorsabb lehet.Egyébként dolgoztam a tiédhez hasonló feladaton, akkor nem így "oszloponként" tároltam a paramétereket (úgy, hogy
id | hajszin | szemszin | ...
), hanem széjjelbontva,
id | param_id | param_value_id
"csoportosításban" (pl. 1 | 5 | 6, ránézve az adatbázisra persze nem túl beszédes, csak a megfelelő tábla hozzákapcsolásával).
Új hozzászólás Aktív témák
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest