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.
Zo te zien schoort er nog wel iets in het database ontwerp, maar wat je nu beschrijft is dus inderdaad prima voor een join.
Voorbeeld:
SELECT...
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.
Het lijkt er nog steeds op dat je database structuur verkeerd is. Ondermeer omdat je dit zegt:
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.
Lol, ik was al met een soortgelijk verhaal bezig. Dus ben het er mee eens ;-)
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... :-)
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.
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 ?
Natuurlijk! Hoe je iets op een pagina toont heeft niets, maar dan ook helemaal niets te maken met hoe het in de database staat. Data laag en presentatie laag zijn niet voor niets in goede applicaties van elkaar gescheiden!
In plaats van de checkboxen jou je ook gewoon 0 stuks kunnen weergeven. Of leeg.
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.
