Hoi allemaal,

in de tool die ik aan het proberen bouwen ben, heb ik wel een veld of 30 waar keuzes uit materialen worden gemaakt. Deze keuzes komen elk in de tabel in een veld.

Als ik nu de "Edit" pagina wil vullen, dan moet ik per veld een nieuwe SQL lookup doen van de waarde van het veld in de tabel.

Dat betekent dat ik PER op te zoeken veld dus een $SQL commando moet uitvoeren en dat in een $row steken.

Kan dit niet op een betere manier ? Het gaat wel degelijk allemaal over aparte velden.

groetjes,

Davy
Aparte velden in één tabel in één of aparte velden in meerdere tabellen in andere records? Hoe zit je datamodel in elkaar en hoe zien je tabellen eruit? Kan je niet alles ophalen in één query?
Aad,

ik heb een tabel met alle materialen waarbij "materiaalID" de index is.
In een tabel waar ik "meubels" heb zitten, heb ik bv voor het veld "corpusmateriaal" een materiaalID zitten (bv 6). In een veld "tabletmateriaal" heb ik een materiaalID zitten (bv 28).

Als ik die velden in een EDIT form dus wil invullen met de naam van het materiaal doe ik een SQL selectie met opzoeken van het materiaalID en dan de naam teruggeven in het veld.

Dat betekent dus dat ik per veld waar ik het gekozen materiaal wil hebben een aparte lookup moet doen, dat is tenminste wat ik denk !

Groetjes,

Davy
Wat is je uitgangspunt, wil je een hele berg materialen tegelijk editten of wil je een bepaald item editten, bijvoorbeeld een of meerdere meubels. Je kan dan de tabel materialen en de tabel meubels joinen. Of in een ander geval, tablets editten, de tabel materialen en de tabel tabletmateriaal joinen. Wil je alles tegelijk editten dan creeer je een union van de eerste en de tweede query. Wordt wel wat uitzoekwerk met updaten....
Eigenlijk editeer ik telkens 1 meubel.
Maar, elk meubel bestaat uit onderdelen (zoals bv een deur en een zijkant).
Beide onderdelen "kunnen" uit verschillende materialen bestaan.

Op mijn edit pagina toon ik dus een knop om het materiaal te kiezen voor de deur.
Daaronder toon ik een knop om het materiaal te kiezen voor de zijkant.
Ik toon niet de ID (alhoewel ik die hidden wel bij hou) maar de benaming en de dikte van het materiaal.

Als ik dit meubel ga editeren, zie ik dus beide materialen weer staan bij respectievelijk hun onderdeel.

Ik moet op dat moment via de (hidden) ID weer opnieuw de benaming en dikte gaan opzoeken.


[size=xsmall]Toevoeging op 21/10/2013 22:46:34:[/size]

P.S. Ik wil dus niet de tabel met materialen aanpassen hier !


[size=xsmall]Toevoeging op 21/10/2013 22:50:47:[/size]

Ook al heb ik hier nog niet alle selectie velden aangepast naar knoppen, toch kan de paste misschien wat meer inzicht geven.

Enerzijds heb ik hier de creatie pagina : http://pastebin.com/yCacsRmL

Anderzijds de EDIT pagina die ik nu probeer in orde te krijgen : http://pastebin.com/U8n16TJu
1200 regels code is me iets te veel, dus ik heb niet je code bekeken. Maar in zijn algemeenheid valt te zeggen dat je inderdaad het aantal database calls zoveel mogelijk wilt beperken per pagina.
In jouw geval zou er volgens mij een link moeten zijn tussen product dat je edit, de onderdelen en de materialen. Je zou, grofweg gezegd, een tabel producten moeten hebben, een tabel onderdelen en een tabel materialen. Daarnaast ook een link tabel tussen de onderdelen en de materialen. Als dat zo is, dan kan je alle materialen voor alle onderdelen voor het te editen product met 1 vrij simpele query ophalen. Middels joins kan je alles aan elkaar rijgen.
Erwin,

bedankt voor je antwoord, maar ik vrees dat het hier in dit geval onmogelijk is om met joins te gaan werken. Of ik moet het op dit moment "even niet inzien".

Ik was al aan het denken om de SQL en RESULT te gaan moven naar een functie. Zodoende zijn er nog wel even veel calls maar dan wordt de code toch wat overzichtelijker.

groetjes,

Davy
Onmogelijk is het (bijna) nooit, dus ik zet mijn geld op dat je het even niet ziet. Wat is de structuur van je tabellen en hoe zijn die (voor wat betreft het probleem nu) aan elkaar gelinkt?
In het algemeen kan je stellen, dat je nooit query's uit moet voeren binnen een lus van een andere query, gebaseerd op resultaten van die andere query.
Dit kan in 99,99% van de gevallen met een join opgelost worden.

Ik heb ook niet al je code doorgekeken, als je (met bovenstaande in het achterhoofd) twijfels hebt laat dan de relevante code hier zien.
Ik heb de volgende tabellen :

1. Materiaal
2. Meubels

in de tabel van meubels hou ik voor elke gekozen materiaal (per onderdeel) de ID bij. Dus bv als je dekorzijdes kiest, dan is er in de "meubels" tabel een veld "dekorzijdemat" waarin bv 30 staat.

Is dit een join ? Of gewoon een lookup ?

Ik gebruik die 30 dan als opzoekwaarde om de gegevens van materiaal 30 te vinden en te tonen. Maar die gegevens komen NIET in de "meubels" tabel.

Ik begrijp niet goed hoe een join voor mij hier kan helpen. Dus ik "zie het niet" (sorry daarvoor).
Als ik het zo zie, dan zou je op zijn minst drie tabellen nodig hebben, een stoel heeft houten poten, en lederen rugstuk en een rieten bipszitting dus een stoel kan uit meerdere materialen bestaan, en een ander meubel kan ook uit diezelfde materialen staan.
Kortom een n-n relatie tussen meubels en materialen, dus een koppeltabel.

Reageren