[SQL] 2 of 3 tabellen?
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?
Groeten,
Boris
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).
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.
John schreef op 10.01.2010 23:05:
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.In gegevensmodellering is het ongebruikelijk om de tabel in het meervoud te noemen
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.
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 ;)
groet
Lees ook eens deze tutorial over normaliseren. Door het toepassen van die methode houd je vanzelf het juiste datamodel over...
Dus even voor de duidelijkheid, de huidige structuur:
products
- product_id,
- product_name,
- brand
...
product_dates
- product_date_id,
- product_id,
- product_date_date // Dit is de datum
product_date_prices
- product_date_price_id,
- product_date_id,
- shop_id,
- product_date_price_price // de prijs van de betreffende shop
De tabel product_dates is er dus alleen om meerdere product_date_price records aan 1 datum te koppelen.
Nu vroeg ik me dus af, is het niet beter om er dit van te maken:
products
- product_id,
- product_name,
- brand
...
product_prices
- product_price_id,
- shop_id,
- product_price_date // Dit is de datum
- product_price_price // de prijs van de betreffende shop
Hopelijk is het zo duidelijk?
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.
(En waarom is dat verstandiger? qua ruimte besparing lijkt mij?)
Gewijzigd op 01/01/1970 01:00:00 door Boris Mattijssen
Blanche schreef op 10.01.2010 23:16:
John schreef op 10.01.2010 23:05:
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.In gegevensmodellering is het ongebruikelijk om de tabel in het meervoud te noemen
"Aangezien een tabel meerdere records bevat" is een kul argument om dan de tabel ook in het meervoud te noemen. Tabellen bevatten vrijwel altijd meerdere records. Vrijwel alle datamodellerings(tools) genereren tabelnamen in enkelvoud: product, klant, factuur, order enzovoort. Naamgeving van entiteiten heeft niets met SQL standaards te maken. De (ansi) SQL standaard schrijft niets voor qua naamgeving. Naamgeving standaards worden veelal binnen bedrijven/organisaties opgesteld. Een zeer actuele standaard op dit moment is de Agile standaard: http://www.agiledata.org/essays/dataModeling101.html#IdentifyDataEntities
Hierin lees je bijvoorbeeld: Examples of entities in an order entry system would include Customer, Address, Order, Item, and Tax.
Neem bijvoorbeeld de ORACLE SQL naming convention, die zeggen het volgende:
Quote:
All table names should be plural. If the table name contains serveral words, only the last one should be plural
En nou is ORACLE niet de minste op het gebied van SQL databases.
Kortom, het is wat je zelf het prettigst vind werken. Maar voor mij is nog steeds de meest logische keuze een tabelnaam in het meervoud.
Gewijzigd op 01/01/1970 01:00:00 door Joren de Wit
Quote:
Neem bijvoorbeeld de ORACLE SQL naming conventions, die zeggen het volgende:
Dat zegt Oracle niet, dat zegt een persoon die met Oracle werkt...
Quote:
Maar in de database zou ik de conventie volgen waarbij tabellen altijd een naam in het meervoud krijgen, het zijn immers containers die meerdere entiteiten gaan bevatten. Ze stellen niet 1 entiteit voor.
Dus modelleren in een DBMS is ineens geen gegevensmodellering? Toch wel, het is altijd aan te raden om de enkelvoudsvorm te gebruiken omdat dat een standaard is.
En ja, zo krijg je het ook aangeleerd op school, als je database modelling hebt gehad.
DBA/Developer en geeft niet de mening van Oracle zelf weer.
Jouw stelling "het zijn immers containers die meerdere entiteiten gaan bevatten" begrijp ik niet. Een tabel mag je wat mij betreft container noemen maar het is altijd 1 entiteit en niet meerdere.
Uiteraard is het zo dat wanneer je in een organisatie een naamgevingsconventie maakt en je spreekt daarbij af dat je de tabelnamen in het meervoud zet dat dat een te respecteren keuze is maar ik kan niet anders zeggen dan dat ik in de diverse ict opleidingen altijd geleerd hebt de entiteit te benoemen in het enkelvoud en dat dit vrijwel altijd leidt tot fysieke tabelnamen ook in het enkelvoud en logisch klopt dat ook. De tabel/entiteit klant herbergt een klant en dat kunnen we meerdere zijn ezn.
Op zich zoals jij het geleerd heb heb ik dat ook, alleen is het niet helemaal logisc zoals jij het uitlegt.
De tabel/ entiteit klant herbergt klanten, één regel uit die tabel is een klant, maar het is de "klanten"-tabel. Echter is het een goede gewoonte om tabelnaam_id te gebruiken voor het id van een klant in dit geval. Klanten_id is niet goed, het is een klant_id, omdat het maar van 1 klant is.
Daarom is tabel klant ook logischer.
Echter is er bij dit soort dingen nooit een goede danwel foute optie (naja, er zijn wel foute opties, maar tussen deze 2 is het gewoon een kwestie van de afspraken die zijn gemaakt)