Door
Ferdi R
op 25-03-2015 21:54
gewijzigd op 25-03-2015 22:11
3.171 views
Ik wil voor een aantal verzamelaars een database maken voor verschillende producten, maar ik zit te twijfelen hoe ik dit zou opbouwen omdat je juist met verschillende producten werkt.
Zal ik per product/categorie een nieuwe database aanmaken of alleen een nieuw tabel? een nieuw tabel aanmaken betekend dat ik veel tabellen krijg in de database.
Moet ik nu voor elke filter ook een databasetabel aanmaken? of weet iemand een andere oplossing.
Het probleem waar ik ook mee zit is dat een merk (bijvoorbeeld Nintendo) ook een uitgever kan zijn. Of het Merk Sony Playstation kan ook de label Sony zijn.
En wat als je dadelijk subsubcategorieën hebt? Nu zit je vast aan twee nivea's (en mogelijk twee tabellen). Je zou ook kunnen overwegen een boomstructuur (in één tabel) te maken - dan kun je je (boom)structuur indelen als je wilt mits deze aan een boomstructuur blijft voldoen, anders moet je misschien aan een soort van veel-op-veel-relatie constructie gaan denken.
Ik denk dat ik maar voor elke categorie een nieuwe database maak want voor elke categorie zijn er teveel verschillende filters, dus ik moet elke categorie behandelen als een nieuwe (website) database.
Ik wil namelijk meer categorieën gebruiken zoals: Games, Muziek, Films, Modeltreinen, Postzegels ect...
Losse tabellen lijkt mij wel vervelend als je vervolgens resultaten uit verschillende categorieën wilt gaan combineren though.
Decisions decisions :).
EDIT: je zou in je database-ontwerp dus rekening moeten houden met wat je met je data doet (hoe je hiermee omgaat), dit houdt ook in: hoe kan ik de database handig opzetten zodat ik vervolgens ook op een handige manier de data er weer uit kan halen.
Hele andere denkrichting wellicht: wat je in feite wilt is het opslaan van kenmerken en deze kenmerken zijn van een type (en misschien zitten deze types in een soort van hierarchie)? De vraag is of je deze associaties keihard wilt vastleggen in je structuur. Je zou ook aan een soort van "losse associaties" kunnen denken. Ooit gedacht aan een soort van "tagging"?
ik denk dat het sneller is als je de filters vooraf definieert.
Nu test je mogelijk met 10 producten en 25 eigenschappen, maar als je straks toch 10.000 producten hebt met 35.000 eigenschappen, dan zou zo'n distinct query zo maar ineens best traag kunnen worden.
