[PHP/MySQL] Text uit extra tabel printen wanneer waarde TRUE

[Verwijderd]

Ik probeer tevergeefs sinds vanmiddag al iets waar ik een redelijk idee over kan vormen maar waarvan ik van mening ben dat het anders moet.

Situatieschets:

Ik heb een tabel met een aantal kolommen, simpel to zover.

Een heleboel info uit de velden die ik selecteer print ik gewoon uit wanneer ik een regel defineer door een variabele. Er zitten ook kolommen in de tabel waar ik "true" of "false" in defineer door een JA of een NEE en met deze Kolommmen wil ik wat doen.

Ik zal even een simpel appels en peren voorbeeld geven, dit moet te begrijpen zijn denk ik:

Iedere regel is een kist. In de kist zitten een aantal fruitsoorten. Ik hbe ook colommen waar staat hoe groot de kist is, de kleur van de kist. maar dit doet verder weinig ter zake.

Ik heb dus dit:

id	kistnaam	afmeting	appel	peer	banaan	pruim	sinasappel
1	kist1		JA	NEE	NEE	NEE	JA
2	kist2		JA	JA	JA	NEE	NEE
3	kist3		JA	JA	JA	JA	JA

Ik kan nu natuurlijk makkelijk een variabele ergens printen met de text ervoor "appel", "sinasappel" of "pruim" waardoor ik : Appel Ja, Pruim NEE en Sinasappel JA kan krijgen, alleen hoe meer producten je zou neerzetten, hoe meer je van die aparte variabelen met extra text als Appel, of Pruim je in je code moet zetten om te printen, dit moet automatisch kunnen.

Ik ben met een extra tabel gaan proberen om wanneer een van de waarden JA is deze automatisch geprint wordt (dat is simpel uiteraard) en uit de andere tabel (de extra dus) op de ID regel de naam van de JA waarde mee te printen, en dit dan voor alles wat JA is voor de regel uit de eerste tabel.

Ik dacht uds aan zo'n 2e tabel of zoiets:

id	appel	peer	banaan	pruim	sinasappel
1	Goudreinet	PEER	Gele Banaan	Geen soort beschikbaar

Ik zou op deze manier Appel makkelijk in Goudreinet kunnen veranderen en pruim in een Soort Pruim.


Ik ben aan de slag gegaan met JOINS en een hele boel queries maar dit ging zeker niet de goede kant op. De info uit de eerste tabel halen en printen is niet zo'n ramp. Vergelijken met de 2e is te doen, maar dan. Hoe print ik in godsnaam die "Gele Banaan" zodat ik daarachter weer "Ja" kan krijgen. En wanneer er "NEE" is kun je gewoon met een IF doen... je print dan gewoon niets. en bij de ESLE zou je dus output van beide tabellen moeten hebben en wanneer ik kist2 aanroep via my query zou ik dit moeten krijgen:


kist2 Goudreinet JA PEER JA Gele Banaan JA


Dit kan neem ik aan niet zonder die extra tabel toch, maar hoe ?

_{Als de titel niet echt smoelt dan moet er een andere gekozen worden ben ik bang}

[flashin]

Ik vind je 2e uitleg niet heel duidelijk maar ik snap je probleem wel.

Ik zou het oplossen met 2 tabellen:

KISTEN

kistid	kistnaam	afmeting
1	kistje	60 units

PRODUCTEN

kistid	product
1	appel
1	peer

Zodat je via 1 query:
SELECT * FROM kisten, producten WHERE kisten.kistid=producten.kistid AND kisten.kistid='1'

dan krijg je dit als output:

kistid	kistnaam	afmeting	product
1	kistje	60 units	appel
1	kistje	60 units	peer

Zo heb je dus geen booleans, maar iedere keer de producten gedefinieerd (dit zou je nog verder kunnen normaliseren, maar goed)

[ Voor 47% gewijzigd door flashin op 06-08-2006 22:59 ]

[seamus21]

Ik zou het oplossen met 3 tabellen. In de trand van flashin.
kist

kistid	kistnaam	afmeting
1	kistje	60 units

product

productid	naam
1	appel
2	peer
3	groene banaan

kist_product

productid	kistid
1	1
1	2
2	1
3	2

Die kist_product is dan een zogenaamde linktabel waarbij je dus twee id's van tabellen aan mekaar knoopt. Nu kun je uit kist_product de gegevens halen die je zoekt.

Je gebruikt dus wele en extra tabel om aan te geven welke producten er in welke kist zitten maar deze oplossing is een stuk netter dan in iedere kolom JA of NEE te gaan printen. Nu kun je dus ook heel veel producten ondersteunen zonder dat je 1 miljoen kolommen krijgt met JA. NEE

[ Voor 27% gewijzigd door seamus21 op 06-08-2006 23:10 ]

[Verwijderd]

Het is me een stuk duidelijker.

Ik was al aan het lezen over Nomalizen voor dat ik het topic gepost had maar was bang dat meerdere tabellen juist niet zo profi zou zijn.

Ik moet zeggen. Het UPDATEN bij meerdere tabellen zal ook sneller moeten gaan (niet dat dat vreselijk veel zal gebeuren maar toch een leuke vooruitgang)

[Verwijderd]

Ik moet dit even updaten, anders wordt het onverzichtelijk.

Ik ben nog aan het bekijken/bedenken. Maar ik dacht juist... Ik maak een tabel2 waarin alle producten beschikbaar zijn bij naam en wanneer er in de eerste tabel een TRUE gegevens wordt voor het product dat je uit de 2e de naam selecteert.

Dit scheelt naar mijn idee ontzetten veel regels per kistid omdat je alles op 1 regel kan zetten en dat in de 2e tabel ook per regel kan stellen omdat de namen beschikbaar zijn daar.

Je zou het kunnen zien als 2 dezelfde tabellen over elkaar heen waarbij de eerste tabel de true voor appel bevat en de 2e op dezelfde plaats de naam van de Appel Soort.

Aangezien het laat is zal ik wel spoken gaan zien

[Verwijderd]

Is dit niet gewoon de makkelijkste oplossing ?

Dit was mijn eerste idee om per regel te controleren, je hebt alleen wel per kolom zo'n stukje script nodig

code:

<? if($row["appel"] == 'Nee'){
} else {
 echo "<tr>";
echo "<td>Appel</td>";
echo "<td></td>";
echo "<td>Ja</td>";
echo "</tr>";
} ?>

Verre van mooi, maar je kunt wel direct alles plaatsen waar je wil.

[Janoz]

Het probleem met je oplossing is dat je je database en je applicatie compleet op de schop moet nemen zodra er een product toegevoegd wordt. Ik zou toch ietsje langer die normalisatie documentatie doornemen. De enige echt juiste oplossing is degene die seamus21 post. Dat is namelijk hoe je een N:M relatie implementeerd.


Edit--
Tenzij er in de kist natuurlijk maar 1 product kan zitten. In dat geval heb je de koppel tabel niet nodig, maar voeg je aan de kist tabel een kolom met het productid toe.

[ Voor 22% gewijzigd door Janoz op 07-08-2006 14:26 ]

[Verwijderd]

Ja, daar hik ik een beetje tegenaan, niet om te lezen wel om het om te bouwen per direct, kan ook binnen een dag of wat.

Maar zou ik hier gewoon een loop van maken die alles uitpoept wat er "beschikbaar" is ? Dus inplaats van dat ik per product een aparte row moet printen ?

^^ dat zou namelijk het het gdoel zijn, anders communiceren we langs elkaar heen.

[Janoz]

Ik raad je aan om er gelijk maar mee te beginnen. Normalizeren is een techniek die al vanaf het begin van relationele database systemen wordt gebruikt. Het is juist de techniek waarop relationele databases zijn gebouwd. Jaren ervaring van miljoenen software engineers hebben aangetoond dat het de meest logische keuze is om te gebruiken tenzij er duidelijk beargumenteerbare redenen zijn waarom een andere indeling handiger zou kunnen zijn.

Nu doorgaan met je eigen brakke model levert alleen maar problemen op. Misschien is deze nog wel makkelijk op te lossen, maar het zal zeker niet het laatste zijn. Zoals ik eerder al aangaf, wat ga je doen als er een product bij komt? Wat ga je doen als je via je applicatie een product toe wilt voegen? Wat ga je doen als je op product wilt zoeken?

[Verwijderd]

Aangezine er alleen content op die manier uitgelezen wordt is het nu niet direct een ramp. Er wordt dus niets geinput op dit moment.

Zoals je zelf zegt, wanneer er een product bijkomt, dit wilde ik in aankomende dagen gaan simuleren en dan zal ik zeker gaan Normalizen.

Het is weer helder... soms heb je even een dip.. ben je dankbaar voor je visie !