Ik zit even met een dilemma of ik 2 of 3 sql tabellen zal gebruiken.
De situatie:
Ik heb een tabel "products" hierin staan alle producten
Ieder dag zijn er nieuwe prijzen, en voor de statistieken moet er een historie worden opgebouwd.
Dus heb ik nog een tabel "product_dates" met de volgende kolommen: product_date_id,
product_id,
product_date_date
En dan dus de prijzen tabel: "product_date_prices" met de kolommen:
product_date_price_id,
product_date_id,
product_date_price_price
Nu is mijn vraag dus, heb ik die tabel "product_dates" nodig of zou ik ook gewoon de structuur van "product_date_prices" aan kunnen passen naar:
product_price_id,
product_id,
product_price_date,
product_price_price
Het gaat erom dat het een redelijk grote database wordt (enkele honderden MB's, en miss wel GB's groot). Dus wat neemt vooral het minste ruimte in beslag?
Nee, die tabel heb je niet nodig. De relatie tussen product_dates en product_date_prices is in principe 1-op-1 aangezien je alleen een record toevoegt zodra een prijs veranderd. Dus de opzet met twee tabellen voldoet.
Verder zou ik aanraden om al die prefixes bij je tabel- en kolomnamen lekker weg te laten. Je queries blijven in een later stadium dan ook nog overzichtelijk. Dus gewoon iets als:
products
----------
id
name
...
prices
-------
id
product_id
start_date
price
Uiteraard zorg je wel dat alle velden van het juiste type zijn en dat je op een slimme manier indexen aanbrengt binnen je tabellen (tip: kijk daarvoor eerst goed naar welke SELECT queries je wilt uitvoeren).
Je hebt een tabel product en een tabel product_prijs nodig.
En kennelijk heb je ook nog een tabel statistiek nodig.
in de tabel product_prijs moet je het product_id meenemen voor de relatie naar product. In gegevensmodellering is het ongebruikelijk om de tabel in het meervoud te noemen: producten. De entiteit is product en er kunnen meerdere records (producten) in aanwezig zijn.
In gegevensmodellering is het ongebruikelijk om de tabel in het meervoud te noemen
Dat ben ik niet met je eens. Veel SQL naamgeving conventies gebruiken juist wel het meervoud voor tabelnamen aangezien een tabel in (bijna) alle gevallen meerdere records zal bevatten. Vooral in je queries is het dan ook logischer om een meervoud te kunnen gebruiken aangezien je bijvoorbeeld 1 product uit een groep van veel producten selecteert.
Of je een tabel statistiek nodig hebt, hangt af van welke statistische gegevens je wilt opslaan. Als je alleen een prijs historie wilt kunnen bepalen, heb je aan deze twee tabellen voldoende. Je weet immers van elk product precies welke prijs op welke data eraan gekoppeld was. Een nieuwe prijs betekent immers een nieuw record met een nieuwe start_date.
excuses, ik zie net dat ik het niet helemaal goed heb uitgelegd.
in de tabel "product_date_prices" is ook nog de kolom "shop_id" (gezien het feit dat wij meerdere shops hebben).
er zijn dus meerdere prijzen records per dag ;)
Als ik het goed begrijp zijn er dus bepaalde producten die in meerdere shops voorkomen? In dat geval zou je ook kunnen volstaan door het shop_id op te nemen in de prices tabel. Voor elke versie van het product (het product in verschillende shops) sla je dan een aparte prijs op.
Lees ook eens deze tutorial over normaliseren. Door het toepassen van die methode houd je vanzelf het juiste datamodel over...
Voor beide oplossingen valt namelijk wat te zeggen, het is net hoe ver je door wilt normaliseren. Het eerste model is qua normalisatie beter, aangezien je een aparte tabel gebruikt voor meerdere records met dezelfde datum.
Wat je jezelf nu moet afvragen is hoeveel van dat soort records je in het tweede model in de product_prices tabel zou krijgen. Zijn dat er slechts enkelen, dan valt te overwegen om de datum daar op te slaan. Zijn dat er echter honderden of duizenden, dan is een aparte tabel zeker een verstandige keuze.
Dat is een punt, maar performance is ook zeker belangrijk. Het zoeken in een geïndexeerde lijst id's is nu eenmaal sneller dat in een lijst met datums. Als je weinig dubbele records zou hebben, zou de tijdwinst bij het selecteren niet opwegen tegen het performance verlies van een JOIN die je dan nodig hebt.
