[MySQL]Kolomnaam is zelf waarde van veld

[mithras]

Ik wil graag bij een profiel van een gebruiker vrijheid geven in de profielinformatie. Je kan dus zelf velden als website, hobby's, woonplaats, opleiding e.d. toevoegen in de database en dan kan de gebruiker deze zelf weer invullen.

Met een normalisatie kom ik uit op het volgende ontwerp:

[b]users[/]
id (int)
name (varchar)
password (varchar)

[b]user_additions[/]
id (int)
name (varchar)

[b]user_additions_values[/]
addition_id (int)
user_id (int)
value (varchar)

Je kan dan als addition een hobby plaatsen (id 2), en in de waarde-tabel krijg je dat gebruiker 1 waarde 'computers' invult voor profielveld 2.

Nu wil ik graag in één query de naam=>waarde koppeling krijgen. Hoe kan ik "user_additions_values.value" AS "user_additions.name" krijgen in MySQL (dus gewoon de informatie: id = 2, naam = Pietje Puk, hobby = Computers)?

Ik heb echt _geen_ idee hoe je het voor elkaar kan krijgen en Google en de MySQL searches leveren niet de gewenste resultaten op (waar zou je op zoeken? "mysql column name from value"?). Bedankt voor elke tip

[B-Man]

Simpel: dit kan niet! Je kunt enkel een rij genereren per veld, per gebruiker. Wat je namelijk probeert te doen is uit een variabel aantal rijen extra kolommen voor de resultset te genereren, en dat kan dus niet.

Iedere user kan ook weer andere velden definieren, alleen al om die reden werkt het niet. Wat ga je immers doen als je meer als een user zou willen opvragen? De twee sets met velden mergen zodat je de combinatie van die twee als kolommen krijgt? Logisch bekeken klopt dat niet, want dan krijgt de n-de gebruiker velden toegekend in de resultset die hij/zij in werkelijkheid helemaal niet heeft opgegeven.

Kortom: je moet dit in code oplossen, niet middels een query.

[ Voor 79% gewijzigd door B-Man op 21-05-2008 14:19 ]

[FireDrunk]

Waarom gebruik je geen "wisseltabel"

id atribute_name attribute_value

Waar id het userid is?

Edit:

En dit in 1 query doen is een kwestie van subqueries gebruiken om de tabel aan je normale user tabel te knopen...

[ Voor 39% gewijzigd door FireDrunk op 21-05-2008 14:19 . Reden: doorlezen 8)7 ]

[B-Man]

thijs_cramer schreef op woensdag 21 mei 2008 @ 14:18:
waarom gebruik je geen "wisseltabel"

id atribute_name attribute_value

Waar id het userid is?

En dit in 1 query doen is een kwestie van subqueries gebruiken om de tabel aan je normale user tabel te knopen...

Als je de regels van normalisatie kent, kun je raden wat het antwoord is: in de structuur die je voorstelt kunnen er dubbele waarden in de kolom "attribute_name" komen te staan, en dat is niet genormaliseerd.

Het is ook niet in 1 query middels subqueries te doen, want dan moet je alsnog zelf de kolomnamen definieren; Daarnaast is het aantal kolommen variabele, dus het aantal subqueries is daarmee ook variabel: zoals je ziet loop je daar vast.

[ Voor 30% gewijzigd door B-Man op 21-05-2008 14:22 ]

[mithras]

B-Man schreef op woensdag 21 mei 2008 @ 14:15:
Simpel: dit kan niet! Je kunt enkel een rij genereren per veld, per gebruiker. Wat je namelijk probeert te doen is uit een variabel aantal rijen extra kolommen voor de resultset te genereren, en dat kan dus niet.

Iedere user kan ook weer andere velden definieren, alleen al om die reden werkt het niet. Wat ga je immers doen als je meer als een user zou willen opvragen? De twee sets met velden mergen zodat je de combinatie van die twee als kolommen krijgt? Logisch bekeken klopt dat niet, want dan krijgt de n-de gebruiker velden toegekend in de resultset die hij/zij in werkelijkheid helemaal niet heeft opgegeven.

Kortom: je moet dit in code oplossen, niet middels een query.

Oke, ik snap het niet helemaal maar volg het toch gedeeltelijk. Ik denk dat je mijn bedoeling niet helemaal hebt meegekregen. Als gebruikers zelf velden definiëren gaat het inderdaad mis.

Wat eigenlijk mijn bedoeling is, dat de "admin" de veldnamen definieert. Ik zeg: ik wil voor al mijn gebruikers een veld "adres", "telefoonnummer" en "email" hebben. Vervolgens zien alle gebruikers de velden en kunnen via "edit profile" de velden een waarde geven.
Uiteindelijk heeft niemand natuurlijk alle velden ingevoerd. Je krijgt dus een gegevens-set als zoiets:

id: 1
name: piet
adres: NULL
telefoonnummer: 0612345678
email: [e-mail]

id: 2
name: jan
adres: hoofdstraat 1
telefoonnummer 0687654321
email: NULL

Kan je het op deze manier wel voor elkaar krijgen?

thijs_cramer schreef op woensdag 21 mei 2008 @ 14:18:
Waarom gebruik je geen "wisseltabel"

id atribute_name attribute_value

Waar id het userid is?

Edit:

En dit in 1 query doen is een kwestie van subqueries gebruiken om de tabel aan je normale user tabel te knopen...

Hoe kan ik bepalen welke velden worden aangemaakt en ingevuld kunnen worden Je krijgt hiermee een normalisatieprobleem zoals B_Man ook aangeeft.

[djiwie]

Zoek eens op "left join".

[Morax]

Je zal altijd minimaal 2 queries nodig hebben.

Wat je wilt kan wel, maar dan zal je eerst een query moeten runnen om op te halen welke extra velden er allemaal zijn, om aan de hand van die resultaten alle joins per extra kolom in je tweede query op laten bouwen.

[Big Womly]

mithras schreef op woensdag 21 mei 2008 @ 14:12:

[b]users[/]
id (int)
name (varchar)
password (varchar)

[b]user_additions[/]
id (int)
name (varchar)

[b]user_additions_values[/]
addition_id (int)
user_id (int)
value (varchar)

id: 1
name: piet
adres: NULL
telefoonnummer: 0612345678
email: [e-mail]

id: 2
name: jan
adres: hoofdstraat 1
telefoonnummer 0687654321
email: NULL

Ik zie het waarschijnlijk veel te symplistisch, maar is dit niet wat je wil hebben?

code:

select u.id, u.name, ua.name, uav.value
from users u, user_additions ua, user_additions_values uav
where uav.user_id = u.id
  and uav.addition_id = ua.id;

met dus de string "email" in user_additions.name en "[e-mail]" in user_additions_values.value

[ Voor 19% gewijzigd door Big Womly op 21-05-2008 15:03 ]

[MueR]

Maar volgens bovenstaande manier krijg je wel voor elk veld een aparte rij terug. Je kan dus net zo goed gewoon een 2e query maken.

[Niemand_Anders]

Het eenvoudigst (en snelst/efficientst) is het gebruik van twee queries zoals hierboven aangegeven (1 voor de gegevens uit je 'basis' tabel en een query welke alle custom velden ophaalt.

Als je beide queries vervolgens omzet naar een array, dan kan je UI code gewoon alles uit de array halen. arrays en collecties zijn in dit geval eenvoudig in gebruik dan een object met dynamisch properties vanwege de noodzaak van veld iteratie.

code:

//handle query 1
fields["userid"] = basicRow["id"];
fields["firstname"] = basicRow["fname"];
fields["lastname"] = basicRow["lname"];
fields["email"] = basicRow["email"];

//handle query 2
foreach(key+value in resultset)
    fields[key] = value

[mithras]

Mm, ja ik denk dat die manier de makkelijkste is inderdaad. Ik koppel nu dus "maar" de twee query's in php aan elkaar. Het was niet mijn uitgangspunt (het moest mooier kunnen ), maar wel verreweg de snelste in vergelijking met onmogelijke queries die te veel resources in nemen (als het dus überhaupt wel kon).