[PHP/MySQL] bepaal "de echte" kolomnaam ipv de AS kolomnaam

[0528973]

Wanneer de query:

code:

SELECT `foo` AS `bar` FROM `foobar`

(Wat ik nu heel graag zou willen, is via een PHP of MySQL functionaliteit dat de kolom `foo` een ALIAS `bar` heeft gekregen en dat we daarom de variabele `bar` tegenkomen in onze MySQL resultset.)

uitgevoerd wordt in PHP tegen een MySQL Server en je vraagt het MySQL result op dan zit in het resultaat van MySQL de array index of property(afhankelijk van gebruikte PHP functie) `bar` terwijl er op dat moment in de situatie hier het nodig is, om te weten dat er `foo` geselecteerd is.

Het probleem: "Is het mogelijk om zonder omwegen te bepalen in PHP of MySQL, dat niet de kolom `bar` geselecteerd is, maar dat `bar` een alias is van `foo` ?" Voorzover er gevonden kan worden, zijn er geen MySQL queries of PHP functies, die de mapping tussen ALIASSEN en "echte namen" uit een Query of Resultset terug kunnen krijgen. Wat nu dus betekent dat er of een Query Parser geschreven of hergebruikt moet gaan worden om deze mapping alsnog te kunnen verkrijgen.

-- Onderstaande is een kleine toevoeging waaraan gezien kan worden, naar welke opties er gekeken is om dit probleem op te lossen dmv PHP of MySQL --
DESCRIBE, EXPLAIN, SHOW COLUMNS, SHOW FULL COLUMNS en al hun bijbehorende PHP-functies leveren alleen maar de ALIAS naam op van de "echte" kolom. Nu is het natuurlijk mogelijk om een hele leuke complexe reguliere expressie te schrijven welke, alle kolommen ophaalt waarvoor een ALIAS ingesteld wordt in de query, dit is alleen op den duur niet echt onderhoudbaar/robuust & flexibel genoeg(zoals djluc idd aangeeft). Ik verwacht op dit moment niet dat het mogelijk is met MySQL 4.1 en PHP 4.3

-- De reden waarom dit probleem opgelost moet worden --
We zijn hier een hele mooi classe aan het schrijven, welke op basis van een Query heel leuk een lijst op het scherm zet, met allerlei browse & sorteer opties als de lijst langer als X elementen wordt. Nu valt natuurlijk te zeggen, pas je classe zo aan dat je geen ALIAS constructies in je Query toelaat. Dit is echter niet wat er moet komen, we willen een lister schrijven, welke op basis van welke Query dan ook(Zolang het een SELECT Query is) de geselecteerde elementen netjes op het scherm kan zetten met wel of geen browse & sorteer opties.

-- Opties --
Indien er geen mogelijkheid is waarmee het ALIAS probleem opgelost kan worden, wordt er gekeken welke beperkingen er allemaal op een Query gelegd moeten worden om de Lister classe alsnog te laten werken. Anders is het nog een mogelijkheid, om de Lister classe zelf de Query te laten maken met alle problemen van dien. Indien blijkt dat deze mogelijkheden te veel problemen met zich mee brengen, gaat de Lister classe vereenvoudigd worden.

-- Bezwaren tegen een Reguliere Expressie --
Te weinig kennis
Complexe Structuur van alles wat er tussen SELECT & FROM staat
alle subopties van de onderstaande regels zijn mogelijk
`database naam`.`tabel naam`.`kolom naam` AS `ALIAS`
"database naam"."tabel naam"."kolom naam" AS "ALIAS"
`database naam`.`tabel naam`.`kolom naam`
"database naam"."tabel naam"."kolom naam"
de ` & " mogen uitgewisseld worden in Queries afhankelijk van een SQL-Variabele, deze
variabele geeft aan dat " gebruikt mag worden

Hoe gaat ik bepalen wat er moet gebeuren als er bijv.

code:

SELECT *, `a`.`foo` AS `bar` FROM `foo` LEFT JOIN `bar` AS `a`

Robuustheid probleem: als er een verandering plaatsvind in de manier waarop MySQL iets doet,
tav ALIASSEN of wanneer ik van Database Back-end wil switchen dan wil ik daar niet mijn
Reguliere Expressie op moeten aanpassen want dan is er in-depth knowledge over alle
uitzonderingen van ALIASSEN in de andere Database Back-end nodig.

[ Voor 42% gewijzigd door 0528973 op 24-08-2005 13:10 ]

[Cavorka]

Ik begrijp er niet echt veel van, maar wat is precies je argument tegen een reguliere expressie over je query? Lijkt me niet echt dat dat een bottleneck wordt... of heb je queries met honderden aliassen? Wat bedoel je met onderhoudbaar/robuust dan?

[djluc]

Volgens mij bedoeld hij eerder flexibel. Het moet bij werkelijk alle queries, hoe gek ook, werken. Dan zou je inderdaad op een kant-en-klaren array van aliassen hopen maar dit bestaat helaas niet.

[WormLord]

Ik begrijp niet precies wat het probleem is, wat je wilt doen dat niet met de aliassen kan.
Maar als je vanuit een willekeurige query die kolom - alias mapping wil halen je weldegelijk met reguliere expressies aan de gang moet gaan.
Wil je dat echt niet, dan kan je nog een query-builder maken met de gewenste functionaliteit, maar dat is niet een echt simpel iets.

Misschien kun je dit probleem omzeilen door sub-queries of temp-tables te gebruiken?

[ACM]

Voor het browsen in een resultaatset en het sorteren maakt het toch niet uit of je de alias of de kolomnaam weet? ORDER BY werkt prima met de uiteindelijke kolomalias en desnoods gebruik je ipv de alias het kolomnummer (ORDER BY 1 etc).

Pagineren is al helemaal niet van de alias afhankelijk, want je bent daarbij afhankelijk van de sortering en verder van LIMIT.

Dus waarom wil je nou eigenlijk die koppeling tussen kolommen en aliassen weten? Voor het toevoegen van extra filtering? Alleen de kolomnaam is dan nog niet genoeg, dan moet je de tabelnaam+kolomnaam (en evt de databasenaam in mysql of schemanaam bij concurrenten) weten...

De mapping is voor zover ik weet inderdaad niet te achterhalen, zonder het analyseren van je querytekst. Maar bedenk dus eerst eens waar je het allemaal voor nodig denkt te hebben.

En wat WormLord al zegt, je kan eventueel ook nog je originele query als subquery in de FROM-list verpakken en dan de extra filtering pas in je laag eromheen uitvoeren. Ditzelfde kan ook met temptables als je een mysql < 4.1 hebt.

[ Voor 13% gewijzigd door ACM op 24-08-2005 14:31 ]