[mysql] tabel indeling

[hilarisch]

ik ben bezig met het bedenken van een indeling van mijn mysql dbase. Nu weet ik echter niet welke methode ik het beste kan hanteren met het volgende probleem.

Ik heb een tabel met daarin producten (met een uniek ID) en allerlei eigenschappen. (ongeveer 3000 prod.)

Daarnaast heb ik een tabel met winkels (met uniek ID) en bv adres en dat soort gegevens. (ongeveer 500)

Nu heeft elke winkel tussen de 50 en 500 producten. En elk product wordt verkocht in ongeveer 50 a 100 winkels.

Nu wil ik kunnen zien welk product in welke winkel wordt verkocht en omgekeerd. En toch nog makkelijk producten en winkels kunnen toevoegen en verwijderen.

Hoe kan ik dit het beste aanpakken?

[ACM]

koppeltabel is het keyword dat je zoekt gok ik.

[hilarisch]

Op vrijdag 21 juni 2002 00:27 schreef ACM het volgende:
koppeltabel is het keyword dat je zoekt gok ik.

ik wist al dat je 3 tabellen nodig had. Producten, Winkels, en eentje voor de relaties.

Maar wat ik me nu afvraag. Hoe maak je dan die koppeltabel.
3 kolommen (relatieID,ProdID,WinkelID) en in de nadeligste situatie ongeveer 50000 rijen lang.

Of maak je dan een tabel met max 100 rijen (prodID,winkelID1,winkelID2,enz.) en dan max 500 rijen lang.

De eerste lijkt me eenvoudiger, maar is die ook wat laadtijd betreft het snelst?

[Femme]

De eerste methode uiteraard. Die 50.000 records hoeven niet zo'n groot probleem te zijn met een goede index (bijv. compound index op ProdID en WinkelID). RelatieID heb je niet nodig.

[ACM]

De 2e is bijna niet werkbaar.

De eerste werkt prima hoor, zeker met een index, maar dat heb je standaard al omdat je in principe de primary key op de combo (prodid, winkelid) 'moet' leggen.
relatieid is idd, zoals femme zegt, in principe overbodig