[SQL] 2 of 3 tabellen?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Boris Mattijssen

Boris Mattijssen

10/01/2010 22:54:00
Quote Anchor link
Hallo allemaal,

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
 
PHP hulp

PHP hulp

04/08/2020 02:05:43
 
Joren de Wit

Joren de Wit

10/01/2010 23:01:00
Quote Anchor link
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).
 
John D

John D

10/01/2010 23:05:00
Quote Anchor link
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.
 
Joren de Wit

Joren de Wit

10/01/2010 23:16:00
Quote Anchor link
John schreef op 10.01.2010 23:05:
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.
 
Boris Mattijssen

Boris Mattijssen

10/01/2010 23:26:00
Quote Anchor link
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 ;)

groet
 
Joren de Wit

Joren de Wit

10/01/2010 23:42:00
Quote Anchor link
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...
 
Boris Mattijssen

Boris Mattijssen

11/01/2010 10:33:00
Quote Anchor link
Dat is inderdaad wat ik nu heb :P
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?
 
Joren de Wit

Joren de Wit

11/01/2010 11:18:00
Quote Anchor link
Aha, bedoel je het zo.

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.
 
Boris Mattijssen

Boris Mattijssen

11/01/2010 11:20:00
Quote Anchor link
Oke dan ga ik dus voor de 3 tabellen. Dankjewel! (:

(En waarom is dat verstandiger? qua ruimte besparing lijkt mij?)
Gewijzigd op 01/01/1970 01:00:00 door Boris Mattijssen
 
Joren de Wit

Joren de Wit

11/01/2010 11:34:00
Quote Anchor link
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.
 
Boris Mattijssen

Boris Mattijssen

11/01/2010 12:26:00
Quote Anchor link
Ok, duidelijk.
 
John D

John D

11/01/2010 12:38:00
Quote Anchor link
Blanche schreef op 10.01.2010 23:16:
John schreef op 10.01.2010 23:05:
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.

"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.
 
Joren de Wit

Joren de Wit

11/01/2010 12:56:00
Quote Anchor link
De conventie die je nu erbij pakt gaat deels enkel over datamodelling en later pas over de naamgeving binnen je (SQL) database. Natuurlijk krijgen objecten/entiteiten een naam in het enkelvoud, dat zal ik niet tegenspreken. 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.

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
 
Richard van Velzen

Richard van Velzen

11/01/2010 13:06:00
Quote Anchor link
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.
 
John D

John D

11/01/2010 13:11:00
Quote Anchor link
@Blanche, Oracle is marktleider en ik ben Oracle OCP en met name de conventie die jij noemt is niet van Oracle. de website Oracle Base is van Tim Hall
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.
 
Robert Deiman

Robert Deiman

11/01/2010 13:15:00
Quote Anchor link
@John
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)
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.