Keresés

én nem szeretem a feladvány jellegű kérdéseket. inkább egy téma, és lássuk mit tud rá azonnal összehordani. meglátszik a tájékozottsága, meg a kommunikációs képességei is.

A join-ok mindenféle változata kedvelt interjú tesztkérdés is szokott lenni.. :-)

Apropó, van listátok arra vonatkozóan, hogy adatbázisos interjúkon miket szoktak kérdezni? 

Ne adja, pláne ha valaki interjúztatott már miket kérdezett? 

jaja. az outer join és is null meglepően hatékony tud lenni minus helyett, ha elég a kulcs alapján minusolni.

pl van egy logtábla, amit purge-olnak, és mindig csak egy hét van benne. én meg archiválni akarom egy saját táblába.

insert into sajat_tabla select * from log_tabla s, sajat_tabla t where s.id=t.id(+) and t.id is null;

Vajk

(Vagy a halmazműveletek közül a MINUS-t.)

(szerintem a 'WHERE NOT EXISTS'-et próbáljuk meg emulálni ezekkel a mesterkélt módszerekkel.)

az elsőhöz kell még egy distinct, és akkor pont ugyanazt adja, kész is. :-(

Így hirtelen azt mondanám, hogy az első n*m és n*(m-1) közötti számú sort fog válaszul adni (n az A sorainak száma, m a C sorainak száma), a második meg A azon sorait, amihez C-ben nincs megfelelő.

Egy kérdés a közösség felé:

Mi a különbség a két query között az eredményt tekintve?

SELECT A.*
FROM  A,
           C
WHERE A.id != C.id;

és

SELECT A.*

FROM A LEFT JOIN C ON A.id = C.id WHERE C.id is null    

Köszönöm

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

CREATE TABLE scott.teszt065 (nev VARCHAR2(100), cim VARCHAR2(100), eletkor Number(3), hajszin VARCHAR2(100));

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;

xmldb-vel tudhatsz ilyet csinalni, de nem lesz szép.

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..

De ez megint csak feladat függvénye. 

Ha olyan programot gyártok, ami egy évben ötször fut tíz percig... bocs, de hol érdekel a performancia?

És megírom, mert esetleg minden futása megspórol öt napi munkát.

szerinted nincs értelme itt tanfolyamot tartani -> nem tartasz. ennyi.

Kérdező=bárki, bármely fórumon, aki feldobott egy kérdést.

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.

Vajk

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.

Erre írta Halaloszto, hogy az ilyen rendszer leíró táblákat - másnéven adatszótár nézeteket - nem ajánlott query-ben használni..

Pontosan. 

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ű'...

Egyébként nem lett volna egyszerűbb megemlíteni, hogy az ALL_TAB_COLUMNS view-ból le tudja kérni? ;)

Az eredeti ez volt, de utána valaki elkezdte feszegetni, hogy hülyeség a dinamikusan változó táblaszerkezet.

Az eredeti kérdés ez volt:

"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. 

Vajk

Nem teljesen egyről. Én a telepítőbe kerülő szoftverről beszéltem, amit felkészítenek a későbbi táblaszerkezet módosítások kezelésére is.

Mondjuk ne okozzon gondot, hogy ha egy módosított  adatbázis alapján kell egy képernyőt/formot generálni.

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.

Vajk

Én is dolgoztam ilyen rendszerben, de

--az alaptáblákhoz nekünk nem volt szabad hozzányúlni

--a kiegészítő táblákat egyszer megterveztük (jól, rosszul) és csak ritkán változott a szerkezetük!

Vajon mely verziók voltak érintettek?

Ezt egyszer én is kinyomoztam, de kíváncsi lennék, javították-e azóta.

Mit értesz dinamikus alatt?

Menet közben, a már működő rendszerben nem.

De hacsak nem tévedek, amíg a gyári telepítőből kész rendszer lett, addig azért bővülhetett az adatbázis.

Legalábbis bennem ilyen emlékek maradtak róla.

(BMC-s idők előtti verzió, az újabbat nem ismerem)

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.

Lásd itt: http://forum.index.hu/Article/viewArticle?a=131977209&t=1001339

a remedy-t hagyjuk, dolgoztam vele. fejlesztőként. nem a legszebb architektúra, de dinamikusan abban sem változott a séma.

Vajk

Az.

Mikor először láttam, azt hittem egy hülye vicc. :((