Ha nem dinamikusan változó nevű (és tartalmú) mezők vannak a táblában/lekérdezésben, hanem a mezők neve és száma fix, akkor nem feltétlenül kell oszlopnevet megjeleníteni a SELECT-ben
INSERT INTO scott.teszt065 VALUES ('Lajos', 'Budapest', 41, NULL); INSERT INTO scott.teszt065 VALUES ('Géza', NULL, 29, 'fekete'); INSERT INTO scott.teszt065 VALUES ('Análka', 'Szeged', Null, 'szőke'); INSERT INTO scott.teszt065 VALUES ('Gizi', 'Pécs', 33, 'barna');
COMMIT;
SELECT nev || CASE WHEN t.cim is not null then ' Cím:' || t.cim end || CASE WHEN t.eletkor is not null then ' Életkor:' || t.eletkor end || CASE WHEN t.hajszin is not null then ' Hajszín:' || t.hajszin end sor FROM scott.teszt065 t;
Egyébként a kérdés / feladat megoldás pont azért vetődött fel, mert ez valóban egy megoldandó feladat.
És pl előfordul, hogy a legtriviálisabb megoldás sem feltétlenül ugrik be..
első körben arra gondoltam, hogy használjunk valamilyen csoportosító függvényt (pl listagg), ötvözve oszlopokra null érték vizsgálattal - és mindehhez valamilyen módon 'belekeverni' az adott oszlop nevét is.
(csak a nem null értékű oszlopok oszlopnevét és mező adatát konkatenálja)
Nem mondom hogy megvan a tiszta megoldás, nem csak üres idő elütése szempontjából kérek tanácsot..
Pont erre gondoltam. Hogy semmiképp ne jusson eszébe olyan cuccot írni, ami futásidőben az all_tab_columns-ot kérdezi. Meg bármi egyéb adatszótárt. Ugyanis azok nagyon nem erre vannak tervezve, óriási performancia szopások lesznek belőle később.
Igaz. De... ha a kérdező nem tudja, akkor rengeteg egyéb dolgot sem. -> minek tanfolyamot tartani?
Ha tisztában van vele, csak épp erre van szüksége... -> minek tanfolyamot tartani?
Ezt sohasem tudtam megérteni.
Kérdezek valamit, akkor a kérdésemre várok választ, nem arra vagyok kíváncsi, hogy mennyire nem értek hozzá.
A fene tudja, a kérdező miért hozta a példáját. Egyáltalán nem biztos, hogy pontosan azt akarja megcsinálni. Lehet, hogy van oka annak is, hogy ezt akarja és annak is, hogyha nem a valós feladatot vázolja.
Kis kezünkkel beírjuk... 60 + oszlopos rekordokat tartalmazó táblákról van szó... így ezt hagytam volna épp ki.
Ha nincs más megoldás hát nincs más megoldás, legalább bepötyögni nem kell, a táblák oszlop szerkezete, azok nevei lekérhetőek, onnantól copy & paste. Csak nagyon csúnya lesz a kód a rengeteget táblanévtől, táblanév konkatenációtól. és ha még csoportosítási függvényt is használunk hozzá akkor még egyszer az osszes 60 oszlop név felsorolva a group by résznél.... 'gyönyörű'...
"2 - hogy lehet oszlopnevet megjeleníteni rekord mezőben?"
A kérdező olyan megoldást keresett, ahol a táblastruktúra (pl oszlopnév) lekérdezhető a select részeként. És erre írtam, hogy a select írásának pillanatában az oszlopnevek ismertek, ergo úgy lehet megjeleníteni hogy a kiskezünkkel beleírjuk.
egyről beszélünk. amikor kész, használják, akkor már nem változik. ezért nincs olyan lekérdezés, amit ne lehetne előre megírni mert még nem ismert hogy a táblának hány és milyen oszlopa lesz. ha meg ismert, akkor simán megírom és kész, nincs kérdés.
Az az Oracle-val is előfordul... ugyebár az ora-1 azt jelenti, hogy valamilyen constraint sérül -- de hogy melyik, azt a hibaüzenet szövegéből kell kinézni, meg kell keresni a zárójelbe tett részt. De ha az egyetlen z betű, akkor valami egybites user magyarra kapcsolta az üzenetek nyelvét.
Még az MS Access függvényeket is fordítják myelvre, ki se tudod kapcsolni, leforditja, aztán futás közben meg nem tudja értelmezni és szétakad. Ostobaság
Az Oracle úgy emlékszem, azért lett olyan, amilyen, hogy bizonyos végfelhasználók maguk turkálhassanak az adataik közt. No persze nem Gizike a recepción.
Ami konkrét példát tudnék, az nagyon szar, de nem azért, mert az ügyfél igényeihez lehet igazítani.
De eszembe jutott másik is: találkoztam például egy Remedy Helpdesk nevű szoftver egy ősi változatával. Az is ilyesmi lehetett és rá viszonylag kevés panasz volt. Ilyesmi alatt értem, hogy volt egy adatbázisa, fix mezőkkel, de azt az igényeknek megfelelően lehetett bővíteni. Sajnos belülről alig ismertem, elsősorban végfelhasználó voltam.
viszont ha van jó megoldás is, akkor inkább példálózzunk azzal, tanuljunk abból.
pl van amit flex-field-nek hívnak.
- a táblában van 20 darab varchar oszlop, attribute01, attribute02 ...
- van egy leíró tábla ami tartalmazza hogy melyik van ezek közül használva, mi a hozzátartozó címke, mi a tárolt adat típusa és format maskja
- a testreszabás a leíró kitöltésével történik
- a kód a leíró alapján kezeli az oszlopokat.
Az hogy az oszlopnévből tudom hogy a UIon az kell legyen hogy 'Lakcím', az nonszenz. És akkor ékezetes oszlopnevek lesznek? És ha le kell fordítani a cuccot szlovákra, akkor át kell nevezni az oszlopokat?
Az igazi kérdés az, hogy hogy kerül a végfelhasználó a Sql*Plus közelébe? Mert normális esetben nem kerül, hanem valamilyen programból (Pro*Cobol-tól PHP-n át Javáig sokminden lehet) érjük el az adatbázist, és abban csináljuk a formázott output előállítását.
