[SQL] Kolom toevoegen aan resultset ?

[Wijnbo]

Vraagje: Is het mogelijk om een extra kolom toe te voegen aan een resultset met waarden uit een andere tabel? Waarbij die andere tabel niets te maken heeft met tabel A.

Bv.

Tabel A:

1,2,3,4,5,6

Tabel B:

a,b,c,d,e

SQL:

SELECT *, <Magic> FROM A AS TEST

Resultaat:

code:

Test | Test 2
1    | a
2    | b
3    | c
4    | d
5    | e
6    | null

[ Voor 22% gewijzigd door Wijnbo op 13-09-2010 08:19 ]

[sopsop]

Je zou een rownum toe kunnen voegen aan tabel B en daar op kunnen left outer joinen?!

http://msdn.microsoft.com/en-us/library/ms186734.aspx

Het blijft natuurlijk geknutsel omdat je een niet logische relatie kunstmatig aan het fabriceren bent.

[ Voor 27% gewijzigd door sopsop op 13-09-2010 08:22 ]

[Verwijderd]

Eigenlijk kan dit sowieso niet omdat bij de join conditie nog niet is gesorteerd. Bij sommige DBMS'en zal dit waarschijnlijk wel werken op de manier die sopsop voorstelt, maar dit moet je echt niet willen. Zorg dat de relatie er wel is, of bedenk een manier waarop dit wel 100% zeker goed zou gaan.

In dit specifieke geval zou het kunnen met SELECT a.*, b.extrakolom FROM a LEFT JOIN b ON ( a.Test = ORD(b.Test) - 96 ). Maar je wilt dit eigenlijk niet

[Danfoss]

^^^ Wat hierboven gezegd wordt.
Alternatief is niet joinen maar dan wordt alles catetisch aan elkaar geplakt.

code:

Test | Test 2
1   | a
1   | b
1   | c
1   | d
1   | e
2   | a
2   | b
2   | c
2   | d
2   | e

Ik kan me alleen niet een situatie bedenken waarom je überhaupt ongerelateerde data op deze manier zou willen ophalen. Waarom wil je dit?

[Wijnbo]

Danfoss schreef op maandag 13 september 2010 @ 08:33:
^^^ Wat hierboven gezegd wordt.
Alternatief is niet joinen maar dan wordt alles catetisch aan elkaar geplakt.

code:

Test | Test 2
1   | a
1   | b
1   | c
1   | d
1   | e
2   | a
2   | b
2   | c
2   | d
2   | e

Ik kan me alleen niet een situatie bedenken waarom je überhaupt ongerelateerde data op deze manier zou willen ophalen. Waarom wil je dit?

Zat al te wachten op die vraag.

Moet uit een tabel met kolom X waarden trekken. Echter, er is ook een kolom Y die true of false is.

Nu moet er een selectie komen waarbij kolom X gesplitst wordt op basis van y

( ik heb het ook niet verzonnen )

Daarom zat ik te denken aan een oplossing door de zelfde tabel opnieuw te selecteren onder een andere naam, en zo de boel aan elkaar te knopen.

Dus:

code:

X  Y
5 1
9 0
2 1
4 0
5 1
6 0
8 1
2 0

Result:

code:

X1 X0
5  9
2  4
5  6
8  2

[P_de_B]

Hoe weet je nu dat uit tabel A de rij met waarde 1 hoort bij de rij met waarde A uit tabel B?

[Wijnbo]

P_de_B schreef op maandag 13 september 2010 @ 08:50:
Hoe weet je nu dat uit tabel A de rij met waarde 1 hoort bij de rij met waarde A uit tabel B?

Dat weet ik niet, "Dat is gewoon zo."

[Woy]

Wijnbo schreef op maandag 13 september 2010 @ 09:10:
[...]
Dat weet ik niet, "Dat is gewoon zo."

Er moet ergens een logica in zitten, anders kan je net zo goed gewoon een random getal selecteren!

[Wijnbo]

Woy schreef op maandag 13 september 2010 @ 09:15:
[...]

Er moet ergens een logica in zitten, anders kan je net zo goed gewoon een random getal selecteren!

Er hoeft geen logica in te zitten, het gaat er gewoon om dat ik 1 kolom splits in 2 kolommen op basis van die kolom met true/false. Dat er precies om het record een true/false staat, is gewoon een gegeven.

Maargoed, jullie zullen vast mijn reactie begrijpen toen ik het zag, en hoorde dat t zo moest.

[Danfoss]

Ik kan me nog steeds niet voorstellen dat er software is dat data zo opslaat.. Weet je zeker dat er niet key in een andere kolom staat die de true en false rijen met elkaar verbind?

Zoniet dan alleen als het 100% zeker is dat rij 1 altijd de true waarde heeft en rij 2 de false waarde en dus de bij elkaar behorende rijen altijd in paartjes achter elkaar staan zou je kunnen joinen op rownumber (rownum = rownum -1).

Maar nogmaals, ik kan me niet voorstellen dat een applicatie het op een dergelijke manier zou opslaan omdat het voor de applicatie zelf dan ook bijna onmogelijk is om de data weer goed terug te kunnen lezen behalve als hij elke keer de hele tabel doorfietst.

[BertS]

zoek je dan niet iets als:

SQL:

SELECT 
     [X], 
     [Y], 
     CASE WHEN [Y] THEN [X] ELSE NULL END AS ColA, 
     CASE WHEN [Y] THEN NULL ELSE [X] END AS ColB 
FROM A

Daarmee splits je tenminste veld X in twee kolommen op basis van de true/false waarde van veld Y.

[ Voor 20% gewijzigd door BertS op 13-09-2010 09:28 ]

[Wijnbo]

Danfoss schreef op maandag 13 september 2010 @ 09:24:
Ik kan me nog steeds niet voorstellen dat er software is dat data zo opslaat.. Weet je zeker dat er niet key in een andere kolom staat die de true en false rijen met elkaar verbind?

Zoniet dan alleen als het 100% zeker is dat rij 1 altijd de true waarde heeft en rij 2 de false waarde en dus de bij elkaar behorende rijen altijd in paartjes achter elkaar staan zou je kunnen joinen op rownumber (rownum = rownum -1).

Maar nogmaals, ik kan me niet voorstellen dat een applicatie het op een dergelijke manier zou opslaan omdat het voor de applicatie zelf dan ook bijna onmogelijk is om de data weer goed terug te kunnen lezen behalve als hij elke keer de hele tabel doorfietst.

Ja Het is een log tabel, die ik moet exporteren naar een rapportje, waarvoor ik een SP moet schrijven. Die SP moet als output 2 kolommen er uit knikkeren.

* Wijnbo huilt.

[Wijnbo]

BertS schreef op maandag 13 september 2010 @ 09:27:
zoek je dan niet iets als:

SQL:

SELECT 
     [X], 
     [Y], 
     CASE WHEN [Y] THEN [X] ELSE NULL END AS ColA, 
     CASE WHEN [Y] THEN NULL ELSE [X] END AS ColB 
FROM A

Daar was ik ook mee aan het experimenteren, maar het probleem is dat het 2 records zijn die 1 moeten worden. Ze zitten ook nog eens in de zelfde tabel

Ik heb het nu trouwens "opgelost",

Door een tijdelijke tabel te maken met de 2 kolommen, eerst kolom 1 vullen op basis van de true resultset, en dan met een cursor er door heen fietsen en elke rij updaten met de zoveelste-waarde-waar-de-cursor-is uit de false resultset.

Performt natuurlijk voor geen meter, maar dat is niet mijn probleem.

[Danfoss]

Wijnbo schreef op maandag 13 september 2010 @ 09:27:
[...]


Ja Het is een log tabel, die ik moet exporteren naar een rapportje, waarvoor ik een SP moet schrijven. Die SP moet als output 2 kolommen er uit knikkeren.

* Wijnbo huilt.

Welke database gebruik je?

In oracle en mssql is dit vrij simpel te doen mits de regel is dat je eigenlijk altijd wil joinen op de vorige rij.
In Oracle het simpelst aangezien die een rownum functie heeft en in MSSQL zul je CTE moeten gebruiken (Common Table Expressions). Voor andere dbms'en weet ik het niet zo 123 maar die zullen vast soortgelijke dingen ondersteunen.

[Janoz]

Ah, het echte probleem is dat er 1 iemand in de opdracht keten boven je verwacht dat je layout taken moet doen met (wiskundige) set operaties.

Dit soort layout acties horen uitgevoerd te worden in je rapportage tool. De reden dat dit zo'n klote probleem is, is omdat sql hier helemaal niet voor bedoeld is.

Ik denk dat je je energie beter kunt steken in de raportage tool dan in de sql.

[Wijnbo]

Janoz schreef op maandag 13 september 2010 @ 09:35:
Ah, het echte probleem is dat er 1 iemand in de opdracht keten boven je verwacht dat je layout taken moet doen met (wiskundige) set operaties.

Dit soort layout acties horen uitgevoerd te worden in je rapportage tool. De reden dat dit zo'n klote probleem is, is omdat sql hier helemaal niet voor bedoeld is.

Ik denk dat je je energie beter kunt steken in de raportage tool dan in de sql.

Joh.

Mooie is dat het in 1 stored procedure er uit moet rollen voor crystal reports. Maargoed, het is al "opgelost"

[cariolive23]

Danfoss schreef op maandag 13 september 2010 @ 09:34:
[...]


Welke database gebruik je?

In oracle en mssql is dit vrij simpel te doen mits de regel is dat je eigenlijk altijd wil joinen op de vorige rij.
In Oracle het simpelst aangezien die een rownum functie heeft en in MSSQL zul je CTE moeten gebruiken (Common Table Expressions). Voor andere dbms'en weet ik het niet zo 123 maar die zullen vast soortgelijke dingen ondersteunen.

PostgreSQL (vanaf versie 8.4) en DB2 kunnen dit ook. Dit is ook beschreven in de SQL standaarden, versie 2003.

[Janoz]

Wijnbo schreef op maandag 13 september 2010 @ 09:39:
Joh.

Dat was jou duidelijk, dat was mij duidelijk, maar gezien de vragen die in dit topic naar voren komen was het nog niet iedereen duidelijk.

Mooie is dat het in 1 stored procedure er uit moet rollen voor crystal reports. Maargoed, het is al "opgelost"

Is dat zo? Wanneer ik deze taak opgelegd zou krijgen, zou ik beginnen te zoeken op de plek waar het daadwerkelijke probleem ligt (en nee, dat ligt primair niet bij de opdrachtgever). Nu ken ik crystal reports niet (tenminste, ik ken het wel, maar heb er nog nooit mee gewerkt), maar als ik een beetje rond google kan ik wel wat pagina's vinden die het over subreports hebben waardoor je meerdere reports in 1 report kunt zetten.