Erre mi lehet a jó megoldás SQL-ben?

termekek.id = tulajdonsagok.termek_id

Ez egy explosion-t eredményez. Annyi sort fog visszaadni, ahány tulajdonsága van a terméknek.

Ilyenkor a legszebb megoldás az lenne, ha 3 külön táblád lenne:

- Termékek: id, név, leírás, amit akarsz.

- Tulajdonságok: id, leírás, stb.

- És egy tábla (kapcsolótábla), ami összekapcsolja a termékeket és a hozzá kapcsolódó tulajdonságokat. Így nem kellene minden tulajdonsághoz egyből rögzíteni egy terméket is.

Tehát ha mondjuk van egy olyan terméket, hogy Pulcsi (id = 1), meg olyan tulajdonságod, hogy Puha (id= 1), akkor a kapcsolótáblában az szerepelne, hogy TermekId: 1, TulajdonsagId: 1.

Aztán ha később lenne egy olyan terméked, hogy Zokni (id = 2), akkor a kapcsolótáblában lenne egy olyan sor, hogy TermekId: 2, TulajdonsagId: 1.

Ha bejönne egy új tulajdonság, mégpedig az hogy Kék és a Pulcsi is kék, akkor megjelenne a kapcsolótáblában egy új sor: TermekId: 1, TulajdonsagId: 2.

Azt, hogy a joinok ne többszörözzék a találataidat, a DISTINCT használatával lehet elérni.

Tehát ennek valahogy így kéne kinéznie:

SELECT DISTINCT TE.*

FROM Termekek TE

INNER JOIN TermekTulajdonsag TT ON TT.TermekId = TE.Id

INNER JOIN Tulajdonsag TU ON TT.TulajdonsagId = TU.Id

WHERE TE.Nev LIKE '%kifejezés%'

OR TE.Leiras LIKE '%kifejezés%'

OR TU.Leiras LIKE '%kifejezés%'

A "SELECT DISTINCT TE.*" azt jelenti, hogy a Termekek táblából válassza ki, a teljesen különböző sorokat.

A szűrési feltételeknél pedig a LIKE '%kifejezés%' nem pontos egyezést vizsgál, hanem azt, hogy tartalmazza-e a mező az adott kifejezést. Tehát ha az a kifejezés, hogy "uh" akkor a "puha" is stimmelni fog rá.

Én csak annyit írnék, hogy #3 válasza nagyon szakmabeli és soknak hangzik elsőre, de ha cégnél lennél akkor egy nagyobb tapasztalattal rendelkező fejlesztő ezt a megoldást választaná.

Persze ez rengeteg dologtól függ, teljesen elképzelhető, hogy a te megoldásod is jó, de #3 válasza szokott lenni általában a megoldás ilyen jellegű problémákra.

#7 vagyok.

A miértet kifelejtettem:D

Programozás területén a jó megoldás azt jelenti, hogy

-más programozó könnyen tudja olvasni a kódodat (ez mindig elsődleges szempont, a bonyolult megoldás nem szép, mindig az egyszerűségre kell törekedni)

-általában nagyon fontos, hogy könnyen lehessen új funkcionalitást adni az adott kódnak

-könnyen lehessen karbantartani, szóval ha van egy borzasztóan bonyolult lekérdezésed, azt fejfájás debugolni és sok idő lehet átírni, ez ugye programozóknál kifejezetten drága mulatság, mert magas az órabérünk, meg termék függvényében fontos a gyorsaság is, hogy tartsuk a lépést a konkurenciával és a user experience is jó legyen

Tehát ezért használjuk nagyon sok esetben #3 válaszát:D természetesen van, hogy csak eléggé komplex lekérdezéssel célszerűbb valamit megvalósítani, ez sem elképzelhetetlen, szerintem aki komolyabban foglalkozik adatbázisokkal, az találkozott már szörnyeteg querykkel:D

“ #7 egy nagyobb tapasztalattal rendelkezo fejleszto inverted indexet valasztana.”

De a kérdező láthatóan az adatbázis építés és a lekérdezés írás alapjaival foglalkozik, szóval semmi értelme már most indexeket keverni ide, főleg egy olyan speciális fajtát amit nagyon ritkán kell használni és szerintem itt sem indokolt. Nem mellesleg nem tudom, hogy mit segítene a rossz táblaszerkezeten vagy magán a lekérdezés megírásán egy index jelen esetben.