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.
amit én gondolok: menet közben a tábla nem változik, ha igen az egy speciális esemény. így a select-et meg lehet írni előre komplett és kész. ha fárad a kezünk, vagy sok tábla van, akkor lehet írni programot ami legenerálja a select-et. ha netán üzemszerűen változik a tábla, akkor a select újraírását is lehet automatizálni. de a select írása/generálása mindenképpen egy design time folyamat, olyan megoldás ami minden futás előtt generálja nem kerülhet éles rendszerbe. egyszerűen azért, mert a használt adatszótár nézetek performanciája igen alacsony, baromira nincsenek terhelésre tervezve. éles működő program nem használhat adatszótár nézeteket.
szerintem a tábla nevének az ismeretében az oszlopokat te is tudod. sőt az is milyen konverziós függvény használj. a végeredmyény kétoszlop. kulcs meg egy szöveg.
mivel előre kell tudd a tábla oszlopainak nevét és számát, bele tudod írni a querybe. amikor a query fut, akkor a tábla létezik, nem kérdés mik az oszlopok.
