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?
[quote='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.
[/quote]
"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.
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 conventions, die zeggen het volgende:
Dat zegt Oracle niet, dat zegt een persoon die met Oracle werkt...
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.
@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.
@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)
