[SQL] Lehetséges szűrési feltételt készíteni egy másik táblából?

#1 Igen, a dinaikus sql-t már néztem, de valahogy nem áll össze... pl ha egy ciklussal legyűjtöm a mezőneveket és értékeket, akkor hogy tudom összefűzni egy where feltételbe?

#2 Hmm. Szerintem pedig nem ugyanarra gondolunk.

Az első táblába pl az alábbi mezők vannak: "name", "age", "location", "phone_number", "email"

A másik táblába pedig csak két oszlop van: `filter_column_name` és `filter_value`.

Ebben pedig értékként fel van véve mondjuk:

"age"-"27"

"location"-"London"

Akkor a lekérdezés legyűjti az első táblából az összes olyan rekordot, ahol a kor 27 és londoni. Ellenben ha bővítem a feltételeket a második táblában, akkor szűkül a lista.

Ezt egy sima JOIN-al nem tudod megoldani, mivel a mezőnevek értékként fognak szerepelni, hiszen nem tudhatjuk előre, hány feltételre szeretnénk szűrni.

#4

Nem az a gond, hanem összefűzni egybe többet is. Mivel a példák amiket találtam, végig iterálnak a rekordhalmazon..

Tehát a

where age = 27

where location = 'London'

szeretném összefűzni. De még próbálkozok vele, mert lehet csak nem látom a fától az erdőt :D

"Amire figyelni kell, hogy kezelni kell, ha nincs feltétel, ha 1 feltétel van és ha több van."

Azt én nagyon egyszerűen szoktam megoldani. Az átláthatóság miatt, mindig új sorba írok minden feltételt egy sima lekérés esetén is, ezért így szoktam (a behúzásokat képzeld oda):

select

*

from

tbl_tabla_neve

where 1=1

and mezo='ertek1'

and masik_mezo='ertek2'

Így ha kikommenteled a feltételeket, akkor is lefut tökéletesen.

Szóval elég közel vagyok a megoldáshoz... de szerintem erre aludnom kell egyet és tiszta fejjel újra elővenni.

#6 Nem az volt a gond... :) Azt csak példának írtam. A ciklust írtam meg hibásan! Azzal bénáztam sokat, mert a változó értékét felülírtam, ahelyett hogy hozzáfűzte volna.

[link]

Végül sikerült.

#8 Igen, a kérdés pontosan a "hogyan" részére irányult. :)

"Erre valószínűleg egy pl/pgsql függvényt írnék"

Igen, ezzel kezdtem: (bármilyen -hatékony- módon, akár plsql is szóba jöhet) Szerintem elsőre tényleg picit felületesen futottad át a kérdést.

"programnyelv, amin már kapcsolódok az adatbázishoz, akkor lehet, hogy abban oldanám meg."

Abban megvan oldva már elég régen, az nyilván nem nagy kunszt. Csak bizonyos esetekben nem hatékony. Például vegyük azt a szkenáriót, hogy van egy kb 1 millió soros bemeneti rekordhalmazod, ami egy terméklista amit a nagyker küld (nem szűrnek semmit, "mert minek?" ezért tele van olyan termékekkel is, amivel az adott kiskereskedő, akinek dolgozol, nem foglalkozik).

A példa kedvéért egy MVC keretrendszerre épülő alkalmazást készítesz és ha a keretrendszer (bizonyos) ORM elemeit szeretnéd kihasználni, akkor a "Product", mint entitás, inputként egy komplett táblát (vagy viewt) akar használni.

Ez persze még mindig "faék", hiszen csinálsz egy view-t, amibe belerakod a szűrési feltételeid és megvagy. Na igen. Aztán jövő hónapban telefonál az ügyfeled, hogy figyi, módosítani kellene a dolgokon, mert a nagyker új márkákat is felvett a listába és azok sem kellenének (vagy épp azok kellenének), most mindegy.

Hamar rájössz, hogy a kódba égetni (bármit is) nagyon nem célszerű (akár egy lekérdezés szintjén sem).

Ekkor 3 utat választhatsz:

a) megpróbálod programkód szintjén "szűrni", de ha nem teszed meg előre, akkor teljesen feleslegesen végzel műveleteket 1 millió rekordon, mert lehet, csak 400-ra van belőle szükség.

b) elengeded a keretrendszer ORM részét és már a bemeneti adathalmazt is lekérdezésként írod meg, viszont ezzel át kell írnod az egész alkalmazást. (soha nem térül meg)

c) betöltéskor leszűröd egy temp táblába, és abból dolgozol. (nyilván ezt választottam)

Ezért arra voltam kíváncsi, hogy megoldható-e ez (fontos: HATÉKONYAN) más módon is és ha igen, akkor hogyan. Ezzel a megoldással, amit az előző válaszomban linkeltem, gyakorlatilag leszűrhető a teljes adathalmaz a kód bármilyen módosítása nélkül is, szimplán adatbázis oldalról, ráadásul a függvény egy táblát ad vissza, amit ha egy view-ban kérsz le, akkor a framework ugyanúgy használhat, mint egy táblát, tehát továbbra is működik az ORM.

Így talán érthető mi volt a célom vele.

Nyilván nem fogom most átírni az alkalmazást (felesleges) mert a temp táblás megoldás is nagyon gyors és hatékony, sőt, ott is megoldható, hogy akár az ügyfél saját magának szerkessze felületről a szűrési feltételeket, tehát a célnak tökéletesen megfelel. Ugyanakkor nagyon érdekelt ez az alternatív megoldás. :)