Hirdetés
- Picit gazdaságosabb és halkabb lett a PlayStation 5 Pro legfrissebb verziója
- Dollármilliárdokért csábított el Zuckerberg egy kínai Manust
- Új versenyző áll rajtvonalhoz a tápok világában
- Tiltott témává tenné Kína az öngyilkosságot az AI számára
- Hálózati sebességre gyúrt a Minisforum új mini-munkaállomása
- Majdnem megfelezi a GeForce GPU-k gyártókapacitását az NVIDIA?
- Pánik a memóriapiacon
- Vezetékes FEJhallgatók
- HiFi műszaki szemmel - sztereó hangrendszerek
- Milyen egeret válasszak?
- Zeneszerkesztő és DJ topic
- Milyen videókártyát?
- SD memóriakártyák (SD, SDHC, SDXC, micro SD)
- Vezetékes FÜLhallgatók
- Úgy állhat le a 16 GB-os GeForce RTX 5060 Ti gyártása, hogy közben nem áll le
Új hozzászólás Aktív témák
-
nyunyu
félisten
Jaj, itt már a relációs adatmodell alapjai is hiányoznak.
Ahogy tm5 írja, ki kéne tenni a kategóriákat egy külön táblába, amiben van egy category_id, és egy name mező.
Mivel ez pártíz-száz különböző értéket fog tartalmazni, ezen akár még a lájk is működhetne gyorsan, nem fájna annyira, mint egy nagyonnagy táblán.Mivel egy termékhez több kategóriát is szeretnél tárolni, illetve egy kategóriába több termék is eshet, így N:M reláció lesz a termék és a kategória között.
Ennek leképezése úgy történik, hogy csinálsz egy termék_kategória táblát, amibe beleteszed a termék azonosítóját, és a kategória azonosítóját.
Ahány kategóriába tartozik, annyiszor veszed fel ide a terméket, mindig a következő kategória azonosítójával.Lekérdezéskor meg joinolod az id-k mentén a három táblát, valahogy így:
select p.*
from product p
join product_category pc
on pc.product_id = p.id
join category c
on c.id = pc.category_id
where c.name like '%akármi%'
order by p.date desc; -
tm5
tag
Szerintem le kellene ülni és összeszedni, hogy mik az elvárások és az alapján tervezni egy adatbázist, mert most minden posztodban kiderül valami újabb dolog.
A category oszlopot inkább kiraknám egy külön táblába, mondjuk úgy, hogy ha van egy category szótárod (cat_id, cat_name) akkor lenne egy un. junction táblád (tabla_id, cat_id)
és akkor cat_id alapján gyorsan tudnál keresni. Ez esetben lehetne az IN operátort is használni. Kerüljük a redundanciát ha lehet. Egy Microsoft SQL-es MVP már 15 éve azt írta, hogy egy rendes 3. normálformájú adatbázis sokkal jobban teljesít, mint egy redundanciával teli.Én amúgy szeretek kompozit indexek helyett külön indexet használni leggyakrabban keresett oszlopokra. Esetleg megpróbálhatod ezt is.
Új hozzászólás Aktív témák
- Telefon felvásárlás!! Xiaomi Redmi Note 13, Xiaomi Redmi Note 13 Pro, Xiaomi Redmi Note 13 Pro+
- Game Pass Ultimate előfizetés azonnal, problémamentesen, méghozzá OLCSÓN! Immáron 8 éve!
- Minden szoftver mellé teljesen audit és NIS2 biztos, jogilag hiteles licencigazolást adunk át!
- Honor 400 Lite / 8/256GB / Kártyafüggetlen / 12Hó Garancia
- Bomba ár! Lenovo X1 Yoga 3rd - i5-8GEN I 8GB I 256GB SSD I 14" FHD Touch I W11 I CAM I Garancia!
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest


