[MySQL] Kolom in JOIN aliassen

[r0bert]

Zoals de titel al zegt, moet ik kolommen die het resultaat zijn uit een join, aliassen. De documentatie van MySQL voorziet daar niet in, dat is op zich al een domper. Toch ben ik benieuwd of er mensen hier een workaround voor weten, afgezien van het gebruiken van de 'oudere' join syntax.

Het liefst dus in deze vorm:

SQL:

SELECT
   `field1` `field$15`
   `field2` `field$16`
   FROM table1
       INNER JOIN table2
           ON `table1`.`field$15` = `table2`.`field$17`

Waarbij field$17 dus een alias zou moeten zijn aan een kolom uit table2.

Graag verneem ik tips en zo mgl. oplossingen

[Noork]

Ik snap het niet. Field 17 staat niet in je select, dus waarom zou je deze uberhaupt moeten aliassen?

[BCC]

r0bert schreef op woensdag 27 augustus 2008 @ 00:02:

SQL:

SELECT
   `field1`, `field$15`,
   `field2`, `field$16`,
   `field$17` as `field17`
   FROM table1
       INNER JOIN table2
           ON `table1`.`field$15` = `table2`.`field$17`

? Wat wil je precies. Die veld namen zijn trouwens om te huilen en volgens mij mis je wat basis SQL kennis. Zijn die dollar tekens in de veldnaam toevallig omdat je anders de verschillende kolommen van verschillende tabellen niet uit elkaar kon houden ?

[ Voor 20% gewijzigd door BCC op 27-08-2008 00:13 ]

[RobIII]

Als die field en table namen "for real" zijn heb ik maar 1 advies: terug naar af. Dan zijn aliassen je kleinste probleem en iets waar je je écht nog geen zorgen om hoeft te maken.



Verder wat Noork in "[MySQL] Kolom in JOIN aliassen" zegt.

[ Voor 24% gewijzigd door RobIII op 27-08-2008 00:24 ]

[_js_]

De enige manier is niet te joinen op de tabel maar op een derived table.

[Voutloos]

_js_ schreef op woensdag 27 augustus 2008 @ 11:12:
De enige manier is niet te joinen op de tabel maar op een derived table.

Erm, waarom begrijp jij de vraag wel, en waar kan ik zo'n glazen bol kopen?

Ik zie in de topicstart nog niets wat niet in en simpele query kan, dus ben ik benieuwd naar verdere toelichting.

[r0bert]

Ok, ik zal andere code weglaten anders krijg ik daar commentaar op.

Zoiets is de bedoeling:

SQL:

SELECT 
     `field1` `user`,
     `field2` `pass` 
   FROM `table1` `usertable`
       INNER JOIN 
           `field1` `surname`, 
           `field2` `familyname` 
       FROM `table2` `userext`
              ON `usertable`.`user` = `userext`.`user`

Maar die syntax achter de INNER JOIN klopt natuurlijk niet.

Mijn vraag is hoe ik nu `table2`.`field1` en `table2`.`field2` wél kan aliassen (in de join)

[ Voor 3% gewijzigd door r0bert op 27-08-2008 11:42 ]

[r0bert]

Aan de 2e reactie begrijp ik dat ik het zo zou moeten doen?

SQL:

SELECT  
     `usertable`.`field1` `user`, 
     `usertable`.`field2` `pass`  
     `userext`.`field1` `surname`,  
     `userext`.`field2` `familyname`  
   FROM `table1` `usertable` 
       INNER JOIN  
            `table2` `userext` 
             ON `usertable`.`user` = `userext`.`user`

Ik zal het proberen

[ Voor 5% gewijzigd door r0bert op 27-08-2008 11:45 ]

[r0bert]

Ok excuses, dat werkt dus gewoon. Ik heb in de documentatie van MySQL alles over de join syntax opgezocht, maar daar kon ik dit dus niet in vinden. Ik dacht dat die table pas bekend zou worden in de JOIN zelf. Blij dat het werkt.

Ben trouwens nog wel even benieuwd waarom die '$' zo fout is?

[Noork]

r0bert schreef op woensdag 27 augustus 2008 @ 11:41:
.........
Mijn vraag is hoe ik nu `table2`.`field1` en `table2`.`field2` wél kan aliassen (in de join)

Je snapt gewoonweg de sql syntax van de join dus niet? In het select gedeelte haal je alles op, dus ook van je 2e tabel. In de join maak je alleen de koppeling tussen 2 velden en doe je verder niks met de kolommen.

Gewoon zoiets dus:

SQL:

SELECT
     tabel1.id,
     tabel1.naam,
     tabel2.id,
     tabel2.waarde AS alias_waarde
FROM
     tabel1
Inner Join tabel2 ON tabel1.id = tabel2.tabel1_id

[edit]aha al opgelost dus, had niet meer ge-F5't.

[ Voor 4% gewijzigd door Noork op 27-08-2008 11:54 ]

[r0bert]

BCC schreef op woensdag 27 augustus 2008 @ 00:11:
[...]

? Wat wil je precies. Die veld namen zijn trouwens om te huilen en volgens mij mis je wat basis SQL kennis. Zijn die dollar tekens in de veldnaam toevallig omdat je anders de verschillende kolommen van verschillende tabellen niet uit elkaar kon houden ?

Nee, deze worden gebruikt om te verwijzen naar tags in de input XML, dat zodoende de juiste namespace eraan geplakt kan worden, afhankelijk van de opgegeven namespace op de database, table of het field zelf (waarbij de laatste natuurlijk de hoogste prioriteit heeft). Zo ziet de XML output er netjes uit. Vanuit het resultfield/resultcolumn zelf is via (PHP) PDO namelijk op zijn hoogst de tablename te achterhalen waarvan het recordfield afkomstig is.

Edit:
Bedankt Noork

[ Voor 93% gewijzigd door r0bert op 27-08-2008 12:04 ]

[Janoz]

r0bert schreef op woensdag 27 augustus 2008 @ 11:51:
Ben trouwens nog wel even benieuwd waarom die '$' zo fout is?

Omdat $ een speciaal teken is. In PHP gaat het je bijvoorbeeld problemen geven omdat bepaalde delen van je query door php ineens als een niet bestaande variabele worden gezien waardoor je de boel moet gaan lopen escapen. Daarnaast is het in 99.99% van de gevallen niet nodig is om een $ te gebruiken om tot een goede kolomnaam te komen.

Daarnaast is het niet alleen de $. Kolomnamen die worden genummerd zorgen voor alarmbellen bij een fatsoenlijke DB ontwikkelaar en namen als 'field' die blijkbaar een user voorstellen zijn al helemaal een onderhoudshel.

[Voutloos]

r0bert schreef op woensdag 27 augustus 2008 @ 11:41:
Ok, ik zal andere code weglaten anders krijg ik daar commentaar op.

Dat is constructief commentaar. We zeggen niet dat je kolomnamen zuigen omdat we het leuk vinden om je af te zeiken, maar gewoon omdat het geen goede kolomnamen lijken te zijn.

[r0bert]

Janoz schreef op woensdag 27 augustus 2008 @ 12:25:
[...]

Omdat $ een speciaal teken is. In PHP gaat het je bijvoorbeeld problemen geven omdat bepaalde delen van je query door php ineens als een niet bestaande variabele worden gezien waardoor je de boel moet gaan lopen escapen. Daarnaast is het in 99.99% van de gevallen niet nodig is om een $ te gebruiken om tot een goede kolomnaam te komen.

Daarnaast is het niet alleen de $. Kolomnamen die worden genummerd zorgen voor alarmbellen bij een fatsoenlijke DB ontwikkelaar en namen als 'field' die blijkbaar een user voorstellen zijn al helemaal een onderhoudshel.

Volgens de MySQL documentatie is een '$'/dollarsign gewoon toegestaan in ALIAS namen. Net zo goed als een '_'/underscore. Ik vind het krom om te zeggen dat een underscore wel correct is, maar een dollarsign niet terwijl ze door de documentatie op één lijn worden genoemd.

Als zulke injection mogelijk was in PHP dan lag de fout niet bij het gebruik van een $/dollarsign maar totaal onveilig PHP code. Zoiets mag natuurlijk nooit kunnen.

De dollarsigns komen niet voor in de kolomnamen, maar in de aliassen. Daarbij staan de genummerde velden symbool voor ieder willekeurige andere kolomnaam, deze kunnen namelijk iedere waarde krijgen (behalve met een dollarsign omdat ik die gereserveerd heb voor mijn aliasreferenties).

Ik zie niet in waarom een dollarsign constructief fout is, behalve dat een programmeur de vrees kan hebben dat zijn PHP code niet 100% veilig is en op deze manier in de waan is dat hij/zij een veiligheidsbarriere in kan bouwen door de MySQL documentatie maar op zij te leggen en net te doen of een dollarsign niet toegestaan is

Voutloos schreef op woensdag 27 augustus 2008 @ 12:49:
[...]
Dat is constructief commentaar. We zeggen niet dat je kolomnamen zuigen omdat we het leuk vinden om je af te zeiken, maar gewoon omdat het geen goede kolomnamen lijken te zijn.

Ja ok Het is goedbedoelt. Maar dan vind ik het ook wel even leuk om erop in te gaan Maar zie hier, het commentaar is er wel

[ Voor 21% gewijzigd door r0bert op 27-08-2008 13:24 ]

[BCC]

Dat het niet fout is wil niet zeggen dat het een goed idee is. Ik zou bijvoorbeeld ook al mijn variabelen var1, var2, var3...etc kunnen noemen. Fout is het niet, maar handig ook niet.

Normaal heeft elke kolom in de database een logische naam, zodat je over een half jaar nog weet wat het ding doet. Natuurlijk is ook hier var1, var2 of zelfs var$_1 correct, maar een omschrijvende naam zoals: "title", "description", "status_code" is een stuk leesbaarder en onderhouds vriendelijker.

[r0bert]

Akkoord, als het om kolomnamen ging klopt dat. Mijn eerste voorbeeld was daar te onduidelijk in (daar werden ze inderdaad gebruikt als kolomnamen), echter irl gebruik ik ze als aliassen.

De kolomnamen heb ik geen zeggenschap over, want die moeten iedere (mysql valid) waarde kunnen hebben die een gebruiker maar wil. Daarom heb ik in het voorbeeld velden als 'field1' gekozen. Deze zullen namelijk in de applicatie best kunnen worden gebruikt door een gebruiker. Maar inderdaad, in dit geval is het voor het topic niet erg duidelijk