[Webscripting] Meerdere shops op één db, produkten per shop

[Config]

Ik zoek een nette oplossing voor het volgende probleem:

Er is een database met produktgegevens, we gaan er even vanuit dat alle produktinfo in 1 tabel staat (naam, ID's, prijzen). Dan hebben we vervolgens meerdere shops die deze produkten laten zien (vanuit dezelfde database). Elk produkt is op een bepaald aantal shops verkrijgbaar, het aantal shops is variabel en veranderd continu.

Vraag: wat voor systeem kan dit goed beheren? Je kan natuurlijk een big-ass matrix maken waar je voor elke shop een colum maakt en dan voor elk produkt een rij, en dan 0 of 1 neerzet als waarde. Dit is zeer ongewenst vanwege de snelheids/onderhouds problemen.

Ik werk het liefst niet met platte files oid maar met databases. BTW ik gebruik in dit geval PHP/MySQL, houdt dus rekening met de limitaties van MySQL please. BTW er zijn nu al een paar redenen om over te stappen op PostgreSQL, als dit probleem wel makkelijk kan worden opgelost met PostgreSQL maar niet met MySQL wil ik dat graag horen, maar primair zoek ik dus een oplossing met MySQL.

NB: het staat wel een beetje 'case studie' achtig nu ik het zo lees, ik zet hier dus even expliciet neer dat het hier geen huiwerkvraag betreft.

[dominic]

Als dit niet om een relationeel database model vraagt dan weet ik het niet meer. Zeer onverstandig om dit met kolommen of platte files op te lossen..

[Verwijderd]

MySql kan dit op zich wel aan (hoewel je geen foreign keys op kan geven).

Op zich zou je elke shop (of meerdere) aan artikelen kunnen koppellen, dat voldoet zo te zien aan je eisen.

Maak er eens een (E)ER model van!

[cwppol]

Een duidelijk geval van Relationele Databases (zoals hierboven al terecht opgemerkt)

Kleine uitleg:
Ieder artikel in een tabel
Iedere winkel in een tabel
en dan een aparte tabel met de relatie (dus: winkel 1 (verkoopt) artikel 2; winkel 1 (verkoopt) artikel 5; winkel 2 (verkoopt) artikel 5. De nummers verwijzen dan dus naar het Id in de andere twee tabellen)

[simon]

Je kunt ook prefix'es werken, dus winkel 1: wink1_tabelnaam enz

[cwppol]

kan, maar dan moet je ieder artikel in iedere winkel opnemen. Da's opzich nog wel handig als de prijs overal anders is, maar als de prijs en spec's overal gelijk zijn is het handiger om de artikelen onafhankelijk van de winkels te bewaren zodat je alles in een keer kunt bewerken.

[Roa]

Je kunt ook prefix'es werken, dus winkel 1: wink1_tabelnaam enz

Das niet zo handig. Ervan uitgaande dat het assortiment telkens veranderd, en, dat staat ook in de 1e post, dat het aantal winkels telkens veranderd, zou ik gewoon 2 tabellen maken, zoals cwppol al zei.

[Config]

Thnx voor de input. Het resultaat is dus nog steeds een tabel die de koppeling voorstelt tussen de 2 tabellen, was ook het enige waar ik op kon komen...was beetje wishful thinking om te denken dat het een stuk mooier kon .

[chem]

Als je een table hebt met de PK op de enige 2 kolommen dan is dat HEEL snel hoor.