Keresés

(mi lenne, ha ez a topik megmaradna a valódi kérdéseknek, az "agytorna" meg mondjuk menne ide: Oracle rejtvények)

Egyformán értelmetlennek tűnik mindkettő.

JOIN agytorna 3 :-)

Kis írásbeli eltérés - jelenthet-e logikai különbséget?

select *

from A left join B on A.kulcs = B.kulcs where B.kulcs is null               

;

select *

from A left join B on A.kulcs = B.kulcs and B.kulcs is null      

?       

az elso hozza a tabla minden sorat mindenkeppen, ha az ID nem egyedi akkor azokat amik megfelelnek a szuresnek annyiszor ahany van belole, ami nem felel meg azt csak egyszer.

a masodik mindet csak egyszer hozza es csak azokat amikre a szuro igaz. az outer join nem szamit, mert minden ID-nek van parja a selfjoin miatt. ha az id nem egyedi, akkor itt is tobbszorozodnek a sorok a selfjoin miatt.

Vajk

(tipikus interjú példa feladat egyike..)  :-)

Join agytorna 2   :-)

Eredmény tekintetében van különbség a két query között? (mindenhol ugyanarról az egyetlen forrás tábláról van szó)

SELECT A.*
FROM table_ugyanaz A,
(SELECT * FROM table_ugyanaz A WHERE A.szuro = valami ) B
WHERE A.id = B.id(+)

-----

SELECT A.*
FROM table_ugyanaz A,
          table_ugyanaz B
WHERE B.szuro = valami
AND A.id = B.id(+)

é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