Dan kan het nog in 1 centrale database, dan moet het alleen in verschillende tabellen. Dat moet geen probleem zijn lijkt mij.
Nee, dan zet je het nog steeds niet in aparte tabellen!
Voorbeeldje: 2 webshops met totaal verschillende producten
Artikelen:
id
omschrijving
Winkels:
id
naam
Assortiment:
id_artikel (foreignkey op de tabel artikelen)
id_winkel (foreignkey op de tabel winkels)
Nu kun je per winkel eenvoudig het assortiment opvragen door gewoon in de query aan te geven voor welke winkel jij de artikelen wilt opvragen. Daar heb je echt geen meerdere tabellen of databases voor nodig. 1 Database kan honderden tot wel duizenden websites bedienen die allemaal hun unieke gegevens bevatten. Dat er aan de achterkant slechts 1 goed genormaliseerde database zit, daar merkt de bezoeker helemaal niets van. De beheerder van de sites merkt daar echter wél wat van: Zijn werk wordt een stuk eenvoudiger!
Edit:
@frank
ik vernam uit betrouwbare bron dat je nederland weereens zou aandoen...
Klopt, ben 3 weken naar Europa geweest, waarvan anderhalve week in een ijskoud Nederland. Dat doe je niet voor je lol kan ik je zeggen! Ben dan ook blij om weer thuis te zijn.
Dan zou je de andere optie van Frank in overweging kunnen nemen, die echter alleen werkt in PostgreSQL: schema's.
Zelf gebruik ik schema's om data en functionaliteit van elkaar te scheiden, maar je zou het kunnen toepassen om gegevens te scheiden, ik heb hier 2 artikeltjes over PostgreSQL geschreven, misschien heb je er iets aan, met name de laatste gaat wat dieper in op schema's en de mogelijkheden daarvan:
Ik zou het graag willen echter aangezien elke website zelfde tabellen krijgen die toch per website verschillend zijn twijfel ik nog steeds.
RJ
Dan heb je dus maar 1 (één!) database nodig. Het enige dat nog ontbreekt, is een tabelletje waarin je aangeeft welke producten/items bij welke website horen. Dus nog even iets verder normaliseren en klaar ben je.
