[megoldva] SQL join egyéni adatokkal

Adatbázis: SQL, XML DB

Hello!

Firebird-ben szeretném megoldani a következő problémát:

Adott egy táblám, ahol az egyik mező a készlet mozgás típusát adja meg. Konkrétan egy smallint mező, az alábbi jelentésekkel:

0 - bevételezés
1 - selejtezés
2 - kiszállítás
3 - visszaszállítás
4 - egyéb

Nyilván a user felé a szöveges megfelelőt kellene prezentálnom, nem a számkódot.

Van-e rá lehetőség, hogy az SQL lekérdezésben a megfelelő számkódhoz rendeljem a szöveges megfelelőt, vagy muszáj leszek létrehozni egy külön táblát ennek az 5 sornak, amit aztán joinolok?

Esetleg hogy máshogy lehet megoldani, hogy egy szimpla SQL lekérdezésben benne legyen minden rekordnál a kódszám és a szöveges megfelelő is?

Előre is köszi a segítséget!

  • 1430 megtekintés

( moha7 | 2010. 09. 15., sze – 14:17 )

Zsír! Pontosan erre volt szükségem!

Köszönöm szépen! :)

( xclusiv v | 2010. 09. 15., sze – 18:34 )

Szia,

Látom, hogy már kaptál választ, de szerintem célszerűbb erre egy táblát felvenni és join-olni, mint query-be hardcode-olni. Ha 25 helyen használod és bővíteni kell (mittomén kitalálnak egy sztornózást vagy ilyesmi) akkor 25 helyen kell belenyúlnod, ami egyrészt szopó, másrészt a hibalehetőségek számát növeli.

Más: lehet, hogy adott esetben célszerűbb magát a string-et tárolnod, akár a numerikus ID mellett akár helyette. Igen tudom, normalizálás meg hibalehetőség meg minden, de néha hasznos.

Ugyanakkor ahogy észrevettem a Firebird jobban szereti a subselect-et, mint a join-t
Vagyis egy

select t1.*
,(select field from t2 where t2.id2=t1.id1) "f2"
from t1

gyorsabb tud lenni, mint a

select t1.*, t2.field "f2"
from t1
left join t2 on t2.id2=t1.id1

x

( tomi66 | 2010. 09. 15., sze – 18:52 )

Ha nem nézzük, hogy miben csinálod, csak azt, hogy mit akarsz és DB és SQL, akkor a normális megoldás az, ha van egy paraméter táblád, amiben a numerikus értékek és a nekik megfeleltetett szövegek fel vannak véve. Utána a join.

Szerintem ennek (készletmozgás-típus szöveges megjelenítése) a megoldására legalább 3 megoldás van:
- külön tábla a típusoknak, annak a PK-ját tárolod a készletmozgás rekordokban
- a mozgástípust szövegesen tárolod a készletmozgás rekordokban
- egyedi ID-t (virtuális PK :) tárolsz a táblában, és query-be case-when vagy if struktúrával beletákolod a megfejtést (vagy ugyanez kliens oldalon hardcode-olva).

Szerintem ez utóbbi a legrosszabb megoldás.

Ez klasszikusan az az eset, amit egy előrelátó programozó paramétertáblával old meg, mert egyszerű, és rögtön elkészíti a toolt, amivel a paramétertábla karbantartható, ergo ha változás van a paraméterekben, akkor azt egy törlés/módosítás/új felvitel művelettel 2 perc alatt elvégezheti akár az is, aki user szinten lélegzik. Az összes többi kókányolás oda vezet, hogy vagy a programozó fog szívni vele a későbbiekben vagy valaki más.

Az enum típust csak az tudja karbantartani, aki a táblákat definiálja, ergo a jövőbeni munkát így biztosítja magának a készítő, ráadásul egy éles rendszerben újra megcsinálni egy táblát, majd töltögetni bele a régi adatrekordokat...hát...nem csak mysql meg pgsql létezik, vannak ennél kevésbé megengedő adatbáziskezelők is. A másik oldal meg hard code szagú...a rossz iskolapéldája.

Szerintem helyzet függő. Lehetőségként írtam. Ha van 8-10 státusz/típus jelző oszlop, akkor már erősen elgondolkoznék, hogy mit alkalmazzak. Persze kevés adatnál tökmindegy.

A delegate pedig legalább olyan jól használható mint a paraméter tábla. És pont ugyanannyira leprogramozható felhasználói oldalra a típusok törlése/módosítása/felvitele. Viszont egy deka join nem kell utána a lekérdezésekhez.