[mysql/php]Variabele table name in join

[douweh]

Hoi,

Ik ben bezig aan een systeem waarbij ik gebieden in een pagina op wil vullen met bepaalde elementen.

Ik heb een tabel die er als volgt uit ziet:

code:

id|page_id|area|element

in mysql sla ik dus op wanneer area "a" op pagina 1 opgevuld moet worden met element "MooiElement":

code:

autoincrement|1|a|MooiElement

Er zijn verschillende 'typen elementen', "MooiElement" en "LelijkElement", dit is uitbreidbaar, misschien wil ik in de toekomst wel een "AnderElement" maken.

Een MooiElement kent zijn eigen variabelen, die opgeslagen worden in een table met de naam "MooiElement".... Namelijk

code:

id|page_id|area|variabele1|variabele2

Elk 'type' element kent dus zijn eigen variabelen... de tabel van "AnderElement" kan naast een id, page_id & area bijvoorbeeld de variabelen "kleur" en "vorm" bevatten.

Het probleem is nu dat op het moment dat ik een pagina genereer, ik ineens alle eigenschappen wil hebben van die elementen... Met 1 query en 1 resultset.

Ik dacht dit te doen door een variabele tablename te JOINEN.

Ik zou dus het volgende terug willen krijgen wanneer ik pagina 3 (met area's a, b en c) opvraag.

code:

2|3|a|MooiElement|ditisdewaardevanvariabele1|ditisdewaardevanvariabele2
3|3|b|AnderElement|rood|vierkant
4|3|c|AnderElement|blauw|cirkel

Ik krijg het echter niet voor elkaar... Is er iemand die mee kan denken? Kan ik dit gewoon oplossen met één query of zit mijn hele opzet uberhaupt niet goed in elkaar?

Bedankt!

[FragFrog]

In plaats van verschillende tables voor aparte elements zou ik 1 table maken met alle elementen en hun ID en in plaats van MooiElement een tabel Element gebruiken met dezelfde waardes + een elementTypeId. Op die manier kun je namelijk wel heel simpel oneindig veel elementen toevoegen en ze toch in 1 simpele query opvragen

//edit

offtopic:
Mwhuaha, Afterlife te snel af

[ Voor 7% gewijzigd door FragFrog op 17-01-2008 20:25 ]

[Verwijderd]

Er zijn bij mijn weten geen databases die iets kunnen als

SQL:

SELECT * FROM (SELECT tabelnaam FROM anderetabel WHERE ...)

en dat is wat jij probeert te doen.
Oftewel, ontwerp zit niet geweldig in elkaar. Dit kun je client side oplossen, maar dat kost je performance (meer roundtrips naar de database), of je zet MooiElement, LelijkElement, AnderElement, etc. allemaal in dezelfde tabel, met een extra veld wat de klassificatie van 't element is (mooi, lelijk, anders).

offtopic:
Chapeau, FragFrog!

[ Voor 3% gewijzigd door Verwijderd op 17-01-2008 20:48 ]

[douweh]

Verwijderd schreef op donderdag 17 januari 2008 @ 20:22:
Er zijn bij mijn weten geen databases die iets kunnen als

SQL:

SELECT * FROM (SELECT tabelnaam FROM anderetabel WHERE ...)

en dat is wat jij probeert te doen.
Oftewel, ontwerp zit niet geweldig in elkaar. Dit kun je client side oplossen, maar dat kost je performance (meer roundtrips naar de database), of je zet MooiElement, LelijkElement, AnderElement, etc. allemaal in dezelfde tabel, met een extra veld wat de klassificatie van 't element is (mooi, lelijk, anders).

Jep, dat is inderdaad precies wat ik probeer te doen.

Probleem is dat de tabel van AnderElement een volstrekt andere tabel is dan die van MooiElement.
(het zijn volstrekt andere zaken, ze kunnen alleen allebei een area innemen...).

Ik snap de rest van je verhaal niet helemaal.... Het probleem zit hem dus juist in het feit, dat elk element andere variabelen heeft (en die dus opgeslagen moeten worden)...

Waarschijnlijk is je verhaal wel logisch hoor, maar ik zit er denk ik te diep in en benader de zaken niet logisch meer...

[Verwijderd]

Aan de database kant kun je dat oplossen met een view (aannemend dat alle *Element tabellen wel een variabele1 en variabele2 equivalent hebben) of met een stored procedure (als jou MySQL versie dat ondersteunt). Of anders toch gewoon client side de gegevens uit de verschillende tabellen bijelkaar halen en presenteerbaar maken.

Disclaimer: ik heb nauwelijks ervaring met MySQL, dus over de specifieke invulling kan ik geen zinnig woord zeggen.

[Verwijderd]

Verwijderd schreef op donderdag 17 januari 2008 @ 20:22:
Er zijn bij mijn weten geen databases die iets kunnen als

SQL:

SELECT * FROM (SELECT tabelnaam FROM anderetabel WHERE ...)

en dat is wat jij probeert te doen.

Oracle heeft daar geen enkele moeite mee en gek is het trouwens ook niet: feitelijk definieer je daar een view...

[ Voor 4% gewijzigd door Verwijderd op 17-01-2008 21:27 ]

[Verwijderd]

I stand corrected, maar ik had er gelukkig 'bij mijn weten' bijgezet...
En gek is 't idd niet, maar de meeste databases ondersteunen 't doodgewoon niet.

[pedorus]

Verwijderd schreef op donderdag 17 januari 2008 @ 21:47:
En gek is 't idd niet, maar de meeste databases ondersteunen 't doodgewoon niet.

Hm, de meeste databases ondersteunen gewoon views/virtual tables. Variabele tabelnamen zoals in de oorspronkelijke post, dat wordt een ander verhaal..

Je zou daarvoor een leuke oplossing met unions en views kunnen bedenken. Of iets met meerdere outer joins. Maar dat wordt al snel een rare oplossing. (Ik zal hem maar niet geven, want dan krijg je iets als dit grapje waar ik een beetje aan moest denken).

Ik denk dat het design beter anders kan. Misschien met een tekst/memo attribuut, twee ongedefinieerde attributen, meerdere queries per pagina, een standaard CMS, XML, of nog iets anders..

[_js_]

Verwijderd schreef op donderdag 17 januari 2008 @ 21:25:
[...]
Oracle heeft daar geen enkele moeite mee en gek is het trouwens ook niet: feitelijk definieer je daar een view...

Oracle heeft er net zoveel moeite mee als elke andere database. We hebben het hier over een variabele tabelnaam, niet over een subquery/view.

Wat veel databases wel kunnen is een string uitvoeren als sql opdracht (in mysql volgens mij alleen vanuit een SP mbv PREPARE), of je kunt alle soorten elementen outer joinen, en met null tests de juiste waardes er uit halen.

Maar als je voor alle verschillende soorten elementen dezelfde gegevens wilt uitlezen, dan denk ik dat de elementen niet zo verschillend zijn, en het dus ook wel in 1 tabel kan.