PHP & MYSQL waarde uit 2 tabellen combineren.

[winux]

Ik heb een script gemaakt, dan taken moet weergeven dus bijv. schoonmaken.
Vervolgens kunnen deze worden afgevinkt en moeten verdwijnen.

Ik heb 1 tabel die (nu nog) bestaat uit id en taak.
Daar komen alle taken in te staan.

Dan heb ik nog een tabel waar de taken in komen te staan als ze gedaan zijn.
Die bestaat uit taak_id, bedrijfs_id en uitgevoerd.

Nou wil ik dat ze taken uit tabel 1 worden weergegeven. En dat hij dus controleert of ze al gebeurt zijn in de tweede tabel. Maar als er nog geen taken zijn afgevinkt staat er dus nog niks in tabel 2 dus moet hij alles weergeven.

Hoe kan ik dit het beste aanpakken?
Ik dacht met joins, maar weet niet zeker.

[Andre-85]

Lijkt me dat het makkelijker is om gebruik te maken van 1 tabel en een kolom toe te voegen.

tabel
id
taak
status (gedaan/niet gedaan)

Op deze manier zijn je gegevens veel beter te beheren.

[NMe]

Andre-85 schreef op dinsdag 26 april 2005 @ 15:35:
Lijkt me dat het makkelijker is om gebruik te maken van 1 tabel en een kolom toe te voegen.

tabel
id
taak
status (gedaan/niet gedaan)

Op deze manier zijn je gegevens veel beter te beheren.

Op deze manier ga je tegen normalisatieregels in.

@TS: probeer eens een outer join?

[winux]

Ja maar de gegevens moeten elke maand terug komen. Plus dat er meerdere bedrijven bij betrokken zijn. Dus als het bij het ene bedrijf is uitgevoerd wil niet zeggen dat het bij het andere bedrijf dan ook gelijk gedaan is.

@modje.
Hoe moet ik dat precie doen?

[ Voor 9% gewijzigd door winux op 26-04-2005 15:39 ]

[Verwijderd]

-NMe- schreef op dinsdag 26 april 2005 @ 15:37:
Op deze manier ga je tegen normalisatieregels in.

Huh? Het lijkt met juist dat het bijhouden van taken in twee tabellen tegen normalisatie-regels ingaat. Het wel of niet gedaan hebben van een bepaalde taak is toch een eigenschap van die taak?

[Andre-85]

-NMe- schreef op dinsdag 26 april 2005 @ 15:37:
[...]

Op deze manier ga je tegen normalisatieregels in.
[...]

offtopic:
Ik weet niet zo heel veel van normalisatie en snap niet waarom dit tegen normalisatie regels in zou gaan. Kun je dat misschien nog ff uitleggen?

[winux]

Die normalisatie is nu niet zo belangrijk. Het gaat mij erom hoe ik dit probleem moet aanpakken.
Kan de mod. Nog ff uitleggen over die outer-join?

[Janoz]

'Normalisatie regels' zijn niet bedoeld om je beperkingen op te leggen, maar juist om problemen op te lossen. Met een join kun je vervolgens de over de verschillende tabellen verspreide gegevens weer samen nemen tot het gewenste resultaat.

[T-MOB]

Ik hou er niet van om met FAQ's te smijten, maar in dit geval staat je antwoord heel duidelijk omschreven in de P&W FAQ.

De query heb je al bijna genoemd in de TS, alleen dan in woorden. Dat zou zoiets moeten zijn:

code:

SELECT * FROM tabel1
LEFT JOIN tabel2
ON (tabel1.taak_id = tabel2.taak_id)
WHERE tabel2.taak_id = NULL

[ Voor 4% gewijzigd door T-MOB op 26-04-2005 16:19 ]

[winux]

Dat werkt niet.

Kan het niet op een andere manier dan met joins?
Kan ik niet gewoon twee queries laten uitvoeren of compleet anders dan twee tabellen gebruiken?
Wie kan me dat zeggen?

[Creepy]

"Dat werkt niet". Wat werkt er niet? Welk resultaat krijg je nu en wat had je verwacht?
Daarnaast: wat heb je nu zelf al geprobeerd om tot het goede resultaat te komen? We verwachten hier dat je zelf ook actief zoekt naar een oplossing.

[froggie]

Leg eens wat meer uit over wat er achter die tabellen gebeurd.

Je hebt een database met daarin taken die uitgevoerd moeten worden. Deze worden uitgevoerd door/'voor 1 of meer bedrijven (iedere keer een vast aantal bedrijven, of is dit variabel?)?

Simpel een join nemen van de 2 tabellen gaat volgens mij niet werken omdat je een soort status per bedrijf wil bijhouden. Dus laat eens horen hoe je proces werkt.

offtopic:
Ik ben van mening dat iedereen zie zich ook maar in de buurt van een (relationele) DB gaat begeven hier eerst eens een degelijk boek over leest. Dan zou over het gros van de schema's een stuk beter nagedacht worden en zouden een hoop van dit soort vragen voorkomen worden.

[ Voor 28% gewijzigd door froggie op 27-04-2005 09:58 . Reden: OT toegevoegd ]

[avdr2]

Dan heb ik nog een tabel waar de taken in komen te staan als ze gedaan zijn.
Die bestaat uit taak_id, bedrijfs_id en uitgevoerd.

Hier is de fout. Er moet ALTIJD een record bestaan voor iedere combinatie van bedrijf en taak. Daarna vul je al of niet het veld uitgevoerd in met een true of een false of een 1 of een 0.

[Rolandow]

avdr schreef op woensdag 27 april 2005 @ 09:57:
Dan heb ik nog een tabel waar de taken in komen te staan als ze gedaan zijn.
Die bestaat uit taak_id, bedrijfs_id en uitgevoerd.

Hier is de fout. Er moet ALTIJD een record bestaan voor iedere combinatie van bedrijf en taak. Daarna vul je al of niet het veld uitgevoerd in met een true of een false of een 1 of een 0.

Bij een left join hoeft dat dus niet. Dan selecteer je altijd alle regels uit de "FROM" tabel, en worden de regels uit de tabel waar je de join op legt alleen geselecteerd als ze er zijn.

Left join moet echt werken.

[sig69]

Ik heb 1 tabel die (nu nog) bestaat uit id en taak.
Daar komen alle taken in te staan.

Dan heb ik nog een tabel waar de taken in komen te staan als ze gedaan zijn.
Die bestaat uit taak_id, bedrijfs_id en uitgevoerd.

Kom op jongens, dit datamodel rammelt aan alle kanten. Lees nou eens goed wat er staat:

Dan heb ik nog een tabel waar de taken in komen te staan als ze gedaan zijn.
Die bestaat uit taak_id, bedrijfs_id en uitgevoerd.

Een tabel met taken, en nog eenzelfde tabel met taken waar ze alleen in staan als de taak is uitgevoerd, met een extra kolom uitgevoerd?

[curry684]

-NMe- schreef op dinsdag 26 april 2005 @ 15:37:
[...]

Op deze manier ga je tegen normalisatieregels in.

@TS: probeer eens een outer join?

Kan aan mij liggen hoor, maar normalisatie schrijft juist voor dat ieder uniek attribuut van een entiteit in de tabel hoort te zitten die die entiteit beschrijft. De status van de taak hoort dus in de tabel taak thuis, en juist het verspreiden van taken over meerdere tabellen overtreedt zo ongeveer iedere regel van 1NV t/m 3NV daar het nutteloos gedupliceerde velden zijn.

Oftewel: dit hoort in 1 tabel zoals sig69 hierboven ook aangeeft, met een foreign key constraint naar een tabel Status die de details van de huidige status aangeeft.

Enige reden om identieke data (in dit geval taken) in meerdere tabellen te zetten is een optimalisatieslag waarbij je data over meerdere databases verdeelt voor performanceredenen. Deze optimalisatiestap dient echter (if at all) pas na uitgevoerd te worden op een uitgenormaliseerde DB. MySQL kan overigens niet eens partitioned views aan dus dat schiet sowieso niet op om op deze manier te optimaliseren, en tis niet echt relevant totdat je een database van een GSM-provider hebt of iets anders dat getikt veel inserts per seconde genereert.

[ Voor 27% gewijzigd door curry684 op 27-04-2005 13:49 ]

[drm]

De relatie tussen taak en bedrijf is er 1 van de vorm n:m *, dat betekent dat er een koppeltabel tussen de tabel die de taken beschrijft en de bedrijven beschrijft ontstaat. Van elke record uit die koppeltabel betekent dat er een relatie tussen een taak A (record uit tabel taak) en bedrijf B (record uit tabel bedrijf) bestaat. Afhankelijk van een eigenschap van die relatie, wordt bepaald of de taak uitgevoerd is of niet. Nu is 't waarschijnlijk nog niet duidelijk, dus:

tabel "bedrijf"
bedrijf_id
naam
...

tabel "bedrijftaak"
bedrijf_id
taak_id
uitgevoerd

tabel "taak"
taak_id
naam
...

Ik denk dat dat ook -NMe-'s idee was en dat -NMe- bang was voor 't idee dat die data allemaal in 1 tabel terecht zou komen, wat inderdaad niet echt de beste toegepaste normaalvorm is

edit:

*) n:m omdat er als voorbeeld schoonmaken genoemd wordt. Dat doe je tenslotte bij wel meer dan 1 bedrijf

[ Voor 11% gewijzigd door drm op 27-04-2005 13:59 ]