[MySQL] Inhoud veld gebruiken als alias in query

[Verwijderd]

Dit lijkt heel simpel, maar ik krijg het niet voor elkaar. Ook googlen hiernaar lijkt onmogelijk.

Ik heb dus bijv een table alsvolgt:

Id	Value	Fieldname
1	Ludo	Voornaam

Dan wil ik dus zoiets doen als:

SELECT t.Value as t.Fieldname FROM table1 t WHERE t.Id=1

en dat ik dus als resultaat krijg

$r['Voornaam'] = "Ludo";

Eigenlijk moet er dus een soort van EVAL() omheen oid.

SELECT t.Value as EVAL(t.Fieldname) FROM table1 t WHERE t.Id=1

[Arjan A]

Hiermee haal je het hele principe van een relationele database onderuit.

Je kan een tabel maken met netjes alle velden erin, of je maakt iets dat dynamisch moet zijn, en in dat geval werk je met twee tabellen:
Eén tabel voor de veldnamen, en één voor de waardes.

Wat jij nu schetst is vast mogelijk, maar ik wil niet eens aan een oplossing denken hiervoor, want dit ziet eruit als iets dat fundamenteel anders moet.

Hopelijk zijn er tweakers die het met mij oneens zijn, zodat ik daar wat van kan leren. Maar met mijn huidige kennis en ervaring denk ik dat je beter je datamodel kan herzien.

[NMe]

Nope, je hebt gelijk. Dit is niet alleen een database in een database (meestal een foute keuze) maar ook nog eens eentje met een afkorting die gewoon niet goed kán werken. Zelfs al is er een manier om dit goed te doen, dan nog zou ik het afraden.

In een relationele database doe je dit, áls je het al moet doen, inderdaad met een tabel voor de values en een voor de keys, en afhankelijk van de toepassing nog eventueel een koppeltabel ertussen.

[Verwijderd]

Ik gebruik dus eigenlijk ook 2 tables, ik had alleen voor de makkelijkheid even gewoon 1 table als voorbeeld gegeven, omdat het principe hetzelfde blijft.

Ik heb het namelijk eigenlijk zo:

TABLE velden

field_id	field_name
8	Voornaam

en

TABLE waardes

value_id	field_id	info_value
1	8	Ludo

en de query wordt dan dus:

PHP:

SELECT w.info_value as v.field_name FROM waardes w JOIN velden v USING(field_id) WHERE 1

[Voutloos]

Goed, dan heb je het iets klein tikkie beter genormaliseerd, maar dat verandert weinig aan het gegeven commentaar.

Als je dan toch deze flexibele zooi nodig hebt, moet je als je je code een beetje leuk opgezet hebt (dus niet op elke willekeurige locatie low level met mysql_fetch_array() etc hacken) toch wel op een enkele plek deze conversie kunnen doen. En dat kan gewoon met wat basis PHP functies, en zeker zonder eval().

[DumbAss]

Klinkt een beetje als EAV. Zoek anders eens op Google naar "mysql eav". Misschien dat je daar wat aan hebt?

[NMe]

Voutloos schreef op zaterdag 21 mei 2011 @ 12:48:
Goed, dan heb je het iets klein tikkie beter genormaliseerd, maar dat verandert weinig aan het gegeven commentaar.

Als je dan toch deze flexibele zooi nodig hebt, moet je als je je code een beetje leuk opgezet hebt (dus niet op elke willekeurige locatie low level met mysql_fetch_array() etc hacken) toch wel op een enkele plek deze conversie kunnen doen. En dat kan gewoon met wat basis PHP functies, en zeker zonder eval().

Precies. In code weet je sowieso wel wat je uit de database aan het halen bent en zelfs als je dat niet weet is het vrij makkelijk om die key/value-pairs in een associatief array of in een on the fly gecreëerd object te stoppen.

[Tsunami]

Je moet het inderdaad niet in je database willen doen, het is simpel om Fieldname en Value te selecteren en die associative array in je programmeertaal op te bouwen.

Maar zo'n opzet lijkt me toch nodig voor metadata? Ik snap dat er nadelen aan zitten zoals het niet kunnen forceren van datatypes op je values, maar wat is het alternatief als je meerdere values per key wil hebben?

[NMe]

Tsunami schreef op zaterdag 21 mei 2011 @ 13:25:
Je moet het inderdaad niet in je database willen doen, het is simpel om Fieldname en Value te selecteren en die associative array in je programmeertaal op te bouwen.

Maar zo'n opzet lijkt me toch nodig voor metadata? Ik snap dat er nadelen aan zitten zoals het niet kunnen forceren van datatypes op je values, maar wat is het alternatief als je meerdere values per key wil hebben?

Er is ook niemand hier die gezegd heeft dat dit soort datamodellen per definitie fout is? Het datamodel kan best goed zijn, om daarover te oordelen ken ik de situatie niet goed genoeg. Wat we hierboven wél allemaal zeggen is dat ludohelder verdomd goed moet weten waarom hij het toepast en dat hij het goed toepast, want echt doorzichtiger wordt het er niet op.

[Tsunami]

Ok, misschien las ik jullie posts dan verkeerd. Dus de keys en values zouden gescheiden moeten worden in aparte tabellen, maar verder is het aanvaardbaar.

[NMe]

Tsunami schreef op zaterdag 21 mei 2011 @ 13:34:
Ok, misschien las ik jullie posts dan verkeerd. Dus de keys en values zouden gescheiden moeten worden in aparte tabellen, maar verder is het aanvaardbaar.

Mits je weet waarom je het doet en waarom het niet beter anders kan, ja.

[storeman]

Ik heb het zelf wel toegepast op een soort webshop. Hierin heb je alle artikelen met enkele generieke kenmerken voor alle artikelen. Echter wil je soms een artikel verder specificeren, alleen weet je niet hoe.

Hiervoor heb ik een tabel 'artikel_type', waarin ik aangeef welke types er zijn. Daaraan gekoppeld een 'artikel_type_eigenschap' tabel, met een naam, label en datatype veld.

Het artikel is vervolgens een artikel_type, dan worden alle aangemaakte eigenschappen ook getoond, naast de standaard eigenschappen. De standaard eigenschappen worden met name gebruikt voor queries en in veel mindere mate draai je de exacte queries op eigenschappen. Hiervoor creeer ik ook wel views voor elk artikeltype, dat maakt het programmeren een stuk leuker. Deze eigenschappen worden weer opgeslagen in een tabel artikel_eigenschappen, met velden:
id_artikel
id_eigenschap
value (TEXT, wordt gevalideerd door programmatuur adhv artikel_eigenschap.datatype)

Overigens zou je dit in postgresql ook met hstore op kunnen lossen

[ Voor 10% gewijzigd door storeman op 21-05-2011 13:58 ]

[Dido]

Ik vraag me af wat de TS verwacht dat er gebeurt als ik ook de achternaam in de tabel opneem.
Iets als dit?

code:

Voornaam Achternaam
Ludo     Helder

Dat gaat niet werken, en ik zie eigenlijk niet waarom je niet gewoon je voornaam kunt selecteren met een where field_id = 8.
En als je alle velden van Ludo wilt hebben, dan heb je met een simpele select van field_id en field_value gewoon een resultset met je key-value pairs.

[Verwijderd]

Voor een dergelijke opzet zou ik eerder een document based oplossing als Couch of Mongo gebruiken, want deze oplossing is wel generiek, maar niet echt superhandig.

Mocht je er wel voor kiezen zou ik niet gaan voor numerieke/surrogaat keys ... voor replicatie zou het makkelijker zijn om text keys te gebruiken, ik hen namelijk weleens de fout gemaakt om deze methode toe te passen en daarna de 'fields' table te droppen, waardoor je niet echt meer weet welk veld wat is.

[NMe]

[list=1]
• De fieldstable droppen is redelijk onhandig, no offense.
• Backups?

Text keys kunnen best handig zijn hoor, maar niet vanwege het argument waar je nu mee komt.

[Verwijderd]

@NMe ... okay true,

voornaamste 'reden' is voor mij altijd geweest dat het leesbaarder is (is meer smaak dan reden) en ook makkelijker te querien omdat je niet altijd hoeft te joinen met een 'fields' table.

-edit-
En ja ... de fields table droppen is erg lomp

[ Voor 12% gewijzigd door Verwijderd op 23-05-2011 10:09 ]

[Davio]

Ik vraag me (na het lezen van de reacties) nog steeds af waarom dit handig zou zijn...

Als je een veld als voornaam hebt, kan dat toch gewoon als een kolom in een gebruikers- of personentabel?


Ik maak het nu wel mee dat we een tabel hebben met verschillende parametercodes, ziet er ongeveer zo uit:

Parametergroep	Parametercode	Omschrijving
OrderStatus	A	Afgehandeld
OrderStatus	P	In productie
OfferteStatus	A	Aangevraagd
OfferteStatus	G	Geaccepteerd

Liever één tabel dan voor elke parametergroep een tabel.


We zijn dit echter aan het uitfaseren ten faveure van enums, wat pas sinds kort een mogelijkheid is voor onze taal (Progress OpenEdge).