Aantal SQL commando's per pagina best zo weinig mogelijk te houden ?
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
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
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.
Toevoeging op 21/10/2013 22:46:34:
P.S. Ik wil dus niet de tabel met materialen aanpassen hier !
Toevoeging op 21/10/2013 22:50:47:
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
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.
Gewijzigd op 22/10/2013 00:10:56 door Erwin H
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
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.
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).
Kortom een n-n relatie tussen meubels en materialen, dus een koppeltabel.
Voorbeeld:
Code (php)
1
2
3
2
3
SELECT...
FROM meubels a
LEFT JOIN materiaal b ON a.dekorzijdemat = b.id
FROM meubels a
LEFT JOIN materiaal b ON a.dekorzijdemat = b.id
En zo kan je voor elk onderdeel de join maken en alles in 1 query ophalen.
Bedenk alleen wel wat Ger zegt. Zo te zien heb je linktabellen nodig, want niet elk meubel heeft elk onderdeel en dus wil je eigenlijk niet in je meubels tabel alle mogelijke onderdelen hebben, maar dat doe je in een link tabel die ik eerder ook al benoemde:
Erwin H op 22/10/2013 00:10:06:
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.
ik probeer me voor te stellen wat jullie bedoelen. En eigenlijk begrijp ik best wat jullie willen zeggen.
Maaaaaar, ik denk dat de manier waarop mijn tool moet werken niet echt op deze manier kan.
Het is idd zo dat er "materialen" zijn. Bv een plank melamime van 4m op 2m met een dikte van 2cm. Dat is voor mij 1 materiaal.
De persoon die het meubel gaat samenstellen, krijgt een scherm te zien waarop hij heel wat zaken kan invullen. De meest normale zaken zijn hoe hoog, hoe breed en hoe diep de kast moet zijn. Na deze waarden in te geven, kiest hij 1 materiaal uit de lijst waarvan de "body" (ook wel corpus genoemd) gemaakt moet worden. In principe kan deze kast nu al klaar zijn, maar er volgt een hele waslijst van mogelijke opties.
Bijvoorbeeld, op één regel kan hij kiezen of er bv een rug (wand) moet zijn. Als hij het vinkje aanklikt, dan moet hij voor die rug opnieuw een soort materiaal kiezen. Dat mag, maar zal meestal niet zo zijn, het zelfde materiaal zijn.
Dan kiest hij of er deuren moeten zijn. Deze deuren gaan dikwijls een ander (mooier) soort materiaal zijn.
Als hij daarna een tweede kast kiest, dan kan de configuratie helemaal anders zijn.
Er lijkt mij dus nergens een "link" (join ?) te zijn op basis van het meubel en de gekozen materialen. Ik houd daarom in mijn tabel gewoon de aangevinkte optie bij en het ID van het gekozen materiaal. Met dat ID kan ik zonder problemen later de naam en dikte van het materiaal gaan opzoeken als dat nodig is.
Maar omdat ik dus zoveel velden in mijn form heb, waarbij ik de naam en dikte wil vermelden, moet ik dus voor ELK aangevinkt veld de naam gaan opzoeken.
Draait dit de zaken om ? Of moet ik alsnog proberen in te zien hoe deze join mij kan helpen ? :-)
Sorry, je ziet waarom het in de "beginners" folder staat.
Groetjes,
Davy
Davy Carmans op 24/10/2013 16:48:36:
Maar omdat ik dus zoveel velden in mijn form heb, waarbij ik de naam en dikte wil vermelden, moet ik dus voor ELK aangevinkt veld de naam gaan opzoeken.
Hieruit maak ik op (maar verbeter me als ik het verkeerd begrijp) dat je een tabel hebt met daarin de keuzes van de gebruiker met een kolom voor elk mogelijke materiaal danwel onderdeel. En alleen die velden waarin een 'vinkje' staat (om het even zo te noemen) zijn geselecteerd. Als dat inderdaad zo is, dan heb je echt een verkeerd model. Dit betekent namelijk dat je een voornamelijk lege database hebt en dat als je er eens een nieuw onderdeel danwel materiaal bijkrijgt dat je je database model moet gaan aanpassen. Dat is echt uit den boze.
Wat je zou moeten hebben is in eerste instantie een splitsing tussen de mogelijke produkten/onderdelen/materialen enerzijds en de opdracht van de klant anderzijds. In principe zijn de produkten/onderdelen/materialen statische tabellen waarin niet vaak iets veranderd. Die hebben gewoon allemaal een id, naam en wat kenmerken.
Anderzijds heb je een tabel 'opdracht' (oid), waarin een klant een opdracht kan gaan maken. Laten we even voor het gemak zeggen dat elke opdracht altijd maar voor 1 produkt is, dus in de opdracht tabel staat een produkt_id (wat linkt naar de tabel produkten, bijvoorbeeld kast, stoel etc). Vervolgens moet de klant hier onderdelen aan linken. Daarvoor heb je dus een linktabel nodig, die de opdracht tabel linkt naar de onderdelen tabel en in die link tabel heb je bijvoorbeeld de velden opdracht_id, onderdeel_id en wat verder nog meer van toepassing is. Ook is er een opdracht_onderdeel_id, zodat je daarmee de volgende kan linken, namelijk de materialen. Per onderdeel selecteer je namelijk 1 of meerdere materialen en daar heb je dus weer een link tabel voor nodig. Daarin heb je dan dus het opdracht_onderdeel_id staan, materiaal_id, kleur, dikte en wat je nog meer belangrijk vind.
Op deze manier is alles aan elkaar gelinkt en kan je het ook met 1 query ophalen.
Nog een bijkomend voordeel is dat je ook nog de onderdelen aan de producten kan linken, want niet elk product kan uit de zelfde onderdelen hoeven te bestaan. (ik heb nog nooit een stoel met een deur gezien)
ik zie het op dit moment nog steeds niet helemaal. Mijn excuses daarvoor.
Waarschijnlijk komt het omdat ik met een "ander verhaal" in mijn hoofd zit.
Is er een manier waarop ik mijn tabelstructuren aan jullie kan laten zien op een makkelijke manier ? Want ik heb nog steeds het gevoel dat mijn verhaal niet strookt met jullie voorstel.
Ik bouw nl geen "stoel" die altijd het zelfde materiaal bevat en zo.
We bouwen meubels op maat die elke keer helemaal anders zijn. Er is nooit geweten of er al dan niet een bepaald onderdeel nodig is.
Ik heb één hoofdscherm waar ik de gebruiker laat kiezen (via checkboxes) of er voor dit meubel een "bepaald" onderdeel nodig is. Als dat aangevinkt is, kan hij dan het soort materiaal kiezen en eventueel extra maten.
Per meubel houd ik alles in één tabel bij met de waarde "1" als een checkbox werd aangevinkt en de ID van het materiaal in het veld voor het materiaal van dat specifieke onderdeel.
Ik ben er van overtuigd dat jullie 100000 keer meer weten dan mij, dus ik ben er van bewust dat ik het plaatje niet helemaal snap... :-)
Groetjes,
Davy
Davy Carmans op 27/10/2013 11:48:06:
Ik bouw nl geen "stoel" die altijd het zelfde materiaal bevat en zo.
We bouwen meubels op maat die elke keer helemaal anders zijn. Er is nooit geweten of er al dan niet een bepaald onderdeel nodig is.
We bouwen meubels op maat die elke keer helemaal anders zijn. Er is nooit geweten of er al dan niet een bepaald onderdeel nodig is.
Juist OMDAT het elke keer anders is moet je die tabelstructuur zo gaan maken zoals Ger en ik zeggen. Juist OMDAT het elke keer anders is wil je zo dynamisch mogelijk linken kunnen leggen tussen product, onderdelen en materialen. Lees nu nog een paar keer mijn vorige post en begin het te snappen.
Verder mag je best jouw tabelstructuur laten zien, maar dat heeft niet zoveel zin als je het mij vraagt want die is verkeerd.
Zoals je het wat mij betreft zou moeten hebben (min of meer):
De statische tabellen met in principe de mogelijk keuzes voor de klant:
Produkten tabel
- produkt_id
- naam
- omschrijving
Onderdelen tabel
- onderdeel_id
- naam
- omschrijving
Materialen tabel
- materiaal_id
- naam
- omschrijving
De tabellen met gegevens per opdracht van de klant:
Opdrachten tabel
- opdracht_id
- klant_nummer
- produkt_id
- aanmaak_datum
Link tabel naar onderdelen
- opd_ond_id
- opdracht_id
- onderdeel_id
Link tabel naar de materialen
- opd_ond_id
- materiaal_id
- kleur
- dikte
- breedte
- diepte
- etc
nogmaals bedankt.
Als ik het via deze nieuwe (betere) manier ga doen, waarvoor mijn dank, kan ik dan nog steeds de gebruiker alle aparte onderdelen laten ingeven op één pagina ?
Groetjes,
Davy
En zodra iemand daar 1 (of meer) van maakt, tel je hem mee.
Scheelt weer een hoop HTML en een hoop controle.
Wat als iemand bij "leggers" wel het vinkje aanzet, maar geen aantal invult?
Laat dan (enkel en alleen) het aantal invullen.
Bij materiaal idem dito: niets opgegeven = niets.
Iets opgeven = ja, blijkbaar willen ze iets.
Let wel dat (bij de materiaalkeuze) dan de mogelijkheid moet zijn om dit weer te verwijderen.