[MySQL] Inhoud veld gebruiken als alias in query

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

Anoniem: 15030

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

Ik heb dus bijv een table alsvolgt:
IdValueFieldname
1LudoVoornaam


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

Acties:
  • 0 Henk 'm!

  • Arjan A
  • Registratie: November 2000
  • Laatst online: 04-07 21:32

Arjan A

Cenosillicafoob

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.

Canon EOS | DJI M2P
Fotoblog · Mijn werk aan jouw muur


Acties:
  • 0 Henk 'm!

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 04-07 15:03

NMe

Quia Ego Sic Dico.

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.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


Acties:
  • 0 Henk 'm!

Anoniem: 15030

Topicstarter
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_idfield_name
8Voornaam


en

TABLE waardes
value_idfield_idinfo_value
18Ludo


en de query wordt dan dus:

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

Acties:
  • 0 Henk 'm!

  • Voutloos
  • Registratie: Januari 2002
  • Niet online
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().

{signature}


Acties:
  • 0 Henk 'm!

  • DumbAss
  • Registratie: April 2002
  • Laatst online: 18-06 13:18
Klinkt een beetje als EAV. Zoek anders eens op Google naar "mysql eav". Misschien dat je daar wat aan hebt?

Vanutsteen.nl => nerds only | iRacing


Acties:
  • 0 Henk 'm!

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 04-07 15:03

NMe

Quia Ego Sic Dico.

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. :)

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


Acties:
  • 0 Henk 'm!

  • Tsunami
  • Registratie: Juni 2002
  • Niet online
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?

Acties:
  • 0 Henk 'm!

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 04-07 15:03

NMe

Quia Ego Sic Dico.

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. :P

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


Acties:
  • 0 Henk 'm!

  • Tsunami
  • Registratie: Juni 2002
  • Niet online
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.

Acties:
  • 0 Henk 'm!

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 04-07 15:03

NMe

Quia Ego Sic Dico.

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. :)

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


Acties:
  • 0 Henk 'm!

  • storeman
  • Registratie: April 2004
  • Laatst online: 22:24
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 ]

"Chaos kan niet uit de hand lopen"


Acties:
  • 0 Henk 'm!

  • Dido
  • Registratie: Maart 2002
  • Laatst online: 19:45

Dido

heforshe

Ik vraag me af wat de TS verwacht dat er gebeurt als ik ook de achternaam in de tabel opneem.
Iets als dit?
code:
1
2
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.

Wat betekent mijn avatar?


Acties:
  • 0 Henk 'm!

Anoniem: 35775

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.

Acties:
  • 0 Henk 'm!

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 04-07 15:03

NMe

Quia Ego Sic Dico.

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

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

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


Acties:
  • 0 Henk 'm!

Anoniem: 35775

@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 Anoniem: 35775 op 23-05-2011 10:09 ]


Acties:
  • 0 Henk 'm!

  • Davio
  • Registratie: November 2007
  • Laatst online: 06-01 16:46
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:

ParametergroepParametercodeOmschrijving
OrderStatusAAfgehandeld
OrderStatusPIn productie
OfferteStatusAAangevraagd
OfferteStatusGGeaccepteerd


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).
Pagina: 1