[database] naamgeving tabellen/velden

[Anders]

Ik merk van mezelf dat ik al niet altijd consequent ben in de naamgeving van tabellen en tabelvelden. Dat komt doordat ik overal wat anders tegenkom, en om wel consequent te kunnen werken wil daarom wat regels voor mezelf (en mogelijk voor het hele bedrijf) opstellen. Probleem is dat ik er niet uit ben wat de beste methode is en ik ben dus benieuwd naar jullie meningen.

Wat voorbeelden van wat ik bedoel (dat ik dus overal op internet en de literatuur andere manieren van naamgeving tegen kom):

code:

(tabel: mix/Mix/tmix)
  id/id_mix/Mix_id
  naam/Name/Mix_Name


(tabel: drank/Drank/Drinks/tDrank)
  id/id_drank/Drank_ID
  naam/Drank_naam/drankNaam

(tabel: drank_mix/dm/drankmix/DrankMix)
  id/koppel_ID/drankmix_id
  id_mix/MixID/id_mix_id
  id_drank/DrankID/id_drank_id

Wat zijn jullie opvatten wat betreft naamgeving? En dan op bijvoorbeeld de punten:

• taal (Nederlands/Engels/door elkaar)
• gebruik hoofd/kleine letters
• naamgeving "primary id" (alleen "id", tabelnaam_id, id_tabelnaam etc)
• naamgeving foreign keys (tabelnaam_id, id_tabelnaam_id etc)
• gebruik underscores en andere tekens

[Blue-eagle]

Ik gebruik altijd de volgende standaard voor m`n tabel namen:
• Altijd Engelstalig
• Tabellen op de volgende manier: tblTopicList, tblUsers
• Andere voorbeelden: tblTopics, tblTopicReplyCombi, tblReplies
• Kolommen in de tabellen: topicName
• Kolommen die een andere tabel joint: topicStatus_LNK

Zo werkt het het makkelijkst bij mij. Gewoon met een standaard werken.
• Tabel voorwaarden: begint met "tbl" en dan een naam die de tabel beschrijft.
• Kolom voorwaarden: begint met de naam van de tabel, daarna een naam die de kolom beschrijft, en dan eventueel de toegevoegde waarde, zoals een inner join, die geen ik aan met "_LNK".
• primary id`s geef ik aan met "_ID"

[Grum]

1/ zoveel mogelijk goed engels
2/ eerste letter capital
3/ bij forgeign keys TableField (dus table met capital en field ook, table enkelvoud)
4/ niet de tabelnaam in et field herhalen
5/ linktabellen altijd degene die 'grouped' eerst en dan de 'variabele' GroupVariables (2e meervoud)
6/ non-link tabellen ALTIJD meervoud
7/ geen prim-key in de linktabellen (gewoon unique op combo van de keys)
dus zoiets:

Mixes
- Id
- Name

Drinks
- Id
- Name

MixDrinks
- MixId
- DrinkId

zoiets dus (beetje chaos lijstje ), maar smaken verschillen

btw: dit is dus alleen handig in mysql .. in mssql gebruik ik wel tbl voorvoegsels voor de tabellen omdat je daar ook views/stored procedures hebt

[Crazy D]

Een tabelnaam begint bij mij vaak met t, tDrank. Een view met een v, vDrankVerbruik en stored procedures met sp, spKanEffeNiksVerzinnen
Nederlands of Engels is een beetje afhankelijk van wat het is, ik vind het vooral belangrijk dat de naam duidelijk is. Hoofd- en kleine letters heb ik geen problemen mee. Scheelt misschien ook dat ik meestal mssql gebruik en die zal het een worst wezen of er hoofdletters in een tabelnaam zitten of niet.
Veldnamen ben ik niet heel erg consequent in. In jouw voorbeeld je zou de dranken tabel dus tDrank heten en de drId en drNaam.
tMix met mixId en mixNaam.
tDrankMix met dmMixID en dmDrankID.

Het lijkt meestal wel daarop. Hoewel ik in dit geval denk ik mixid en drankid in die DrankMix tabel waarschijnlijk mixId en drankId zou noemen omdat je imho wel een behoorlijke moet zijn om dan niet te snappen dat drankId verwijst naar tDrank.drId

Ik probeer iig wel altijd consequent te zijn met de prefix, voorkomt sowieso problemen met reserved keywords en dergelijke, aangezien bv user best kan best kan bestaan (als je bedoelt user naam) maar met userId en userNaam is die kans wel klein.
En ik vind het ook makkelijker bij joins ed. Hoef je niet de tabelnaam of tabel-alias voor de veldnaam te proppen als je in 2 tabellen een ID hebt zitten.

Nederlands of Engels is bij mij een beetje afhankelijk waar het voor is. Gewoon een hobby-dingetje voor mezelf die ik anderen nooit laat zien in het Nederlands, projecten voor klanten meestal ook, maar als er zeg maar een kleine kans bestaat dat buitenlanders het gaan zien/mee moeten werken probeer ik wel alles in het Engels te doen. Alleen soms kom ik dan in het Engels uit op tabelnamen van 20 tekens en in het Nederlands een heldere en duidelijke naam van 6 tekens

[RobzQ]

Op woensdag 27 februari 2002 15:32 schreef Grum_ het volgende:

Mixes
- Id
- Name

Drinks
- Id
- Name

MixDrinks
- MixId
- DrinkId

Zo doe ik het ook..

[Grum]

ik snap niet dat mensen kiezen voor

tDrank.drId das toch zonde van je vingers ? (extra tikwerk )

[Crazy D]

Op woensdag 27 februari 2002 15:46 schreef Grum_ het volgende:
ik snap niet dat mensen kiezen voor

tDrank.drId das toch zonde van je vingers ? (extra tikwerk )

Oh my god en ik dacht dat ik lui was
Reden waarom ik dat doe is dat ik dat duidelijker vind. Vooral bij joins, als ik dan bv drNaam zie staan, en mixNaam, weet ik in 1 keer wat waar vandaan komt.

PS en ik hoef bij joins dus niet de tabelnaam of alias ervoor te zetten, dus per saldo hoef ik dan toch minder te typen. Goh ben ik toch nog lui

[Pelle]

Op woensdag 27 februari 2002 15:25 schreef Anders het volgende:
• taal (Nederlands/Engels/door elkaar)

Alles wat Nederlands kan, in het Nederlands, maar ingeburgerde termen als 'users', 'rights' en 'password' enzo natuurlijk gewoon in het Engels.

• gebruik hoofd/kleine letters

Alles kleine letters

• naamgeving "primary id" (alleen "id", tabelnaam_id, id_tabelnaam etc)

id

• naamgeving foreign keys (tabelnaam_id, id_tabelnaam_id etc)

De naam van de tabel waar de FK naar verwijst.

• gebruik underscores en andere tekens

Underscores gebruik ik bij link-tabellen (link_users_rights, link_vacatures_sectoren etc.).

Laatst een docent over de zeik gezien na een 10 weken durende software-engineeringsopdracht met Ingres & Openroad. Er moest een of andere dierentuin applicatie gemaakt worden, op basis van een database.
Voorbeeldje van een tabel zoals deze stond gespecificeerd:

code:

+--------------------------------+
| dieren                 |
+---------+-----------+----------+
| dier_id | dier_naam | geslacht |
+--------------------------------+

Ja, daar beginnen we dus niet aan. Die hele opdracht stond bol van de voorbeelden hoe je géén naamgevingsconventies houdt (in een opdracht voor software ontwikkeling nota bene). En dus maar zelf m'n eigen standaarden erin gemieterd:

code:

+----------------------+
| dier           |
+----+------+----------+
| id | naam | geslacht |
+----------------------+

En natuurlijk hungarian naamgeving van objecten enzo (btnVerzenden in plaats van verzenden_button ).
M'goed.. opdracht laten checken, en die vent werd me daar toch link.. 'ja je houdt je niet aan de specificaties, blah blah blah'. Heeft hij op zich gelijk in, maar als specificaties zo onlogisch zijn dat er geen touw aan vast te knopen is, dan maken we gewoon onze eigen specificaties (de rest van het ontwikkelteam was er dus ook van op de hoogte).. in ieder geval, als het even tegen zit mag ik volgende week al m'n tabellen, queries, procedures en variabelen (jaja!) aan gaan passen

/edit
Nog even een het mix-drink voorbeeldje:

code:

+-----------+
| mix    |
+----+------+
| id | naam |
+----+------+

+-----------+
| drank     |
+----+------+
| id | naam |
+----+------+

+----------------+
| link_mix_drank |
+-----+----------+
| mix | drank    |
+-----+----------+

[tomato]

Laatst nog een stukje over coding conventions geschreven voor een collega. Dit stukje slaat op dit topic:

Tabelnamen geven we altijd een prefix welke aanduidt bij welk project de tabel hoort. Tabelnamen worden nooit hard gecodeerd in SQL queries, maar gedefinieerd in een configuratie bestand.
We beginnen tabelnamen altijd met een hoofdletter. Ieder nieuw woord in een tabelnaam begint ook met een hoofdletter. De naam van een tabel moet altijd goed de inhoud dekken (de betekenis van de tabel moet direct af te leiden zijn uit de naam). Over het algemeen schrijven we tabelnamen in het enkelvoud. We gebruiken alleen alfanumerieke tekens, dus geen spaties, streepjes of underscores.

Voor veldnamen gebruiken we dezelfde regels voor hoofdlettergebruik als bij tabelnamen. Dus we beginnen met een hoofdletter, ieder nieuw woord krijgt een hoofdletter. Ook voor veldnamen gebruiken we geen spaties streepjes of underscores.
Een veldnaam moet volledig uitsluitsel geven over de betekenis van een veld. We gebruiken geen prefixen om de tabel waarin het veld zich bevindt aan te duiden.
De Primary Key in een tabel geven we de naam 'ID' (dus twee hoofdletters). Foreign keys benoemen we door de naam van de gerelateerde tabel te nemen en er 'ID' achter te plakken (bijvoorbeeld 'UserID' voor een FK naar te tabel 'User').

In de SQL queries gebruiken we wanneer er meerdere tabellen aangesproken worden altijd afkortingen van 3 hoofdletters voor een tabelnaam. De tabel 'User' krijgt bijvoorbeeld een alias 'USR'.

Belangrijks vind ik eigenlijk nog wel dat er een standaard is. Wat dit standaard inhoudt boeit wat minder, iedereen heeft zijn eigen smaak.

[Anoniem: 3747]

aj, er zijn verschrikkelijk veel standaards mogelijk. Het belangrijkste is dat je daarmee je werkwijze vereenvoudigd en dat je ook consequent bent.

Een ding kan ik wel zeggen (eigenlijk twee ):
- id van een tabel noem ik altijd ID, in de foreign key verwijs ik ernaar met ID_<tabelnaam>, dus DRANK.ID <-> VERBRUIK.ID_DRANK. Dit is heel erg handig!
- ik begin altijd met het type kolom:
IND_GEBRUIKT, DATUM_VOORVAL, CODE_GEBRUIKER. Daarnaast gebruik ik beschrijvende en uitgeschreven namen, dus niet 'omschr', 'tblX1', 'datum1'. Da's verschrikkelijk om later terug te moeten lezen

[Delphi32]

Voor het probleem van de verwijzende ID-velden gebruik ik altijd FK_* (* = tabelnaam).
Dus:
Mix (Id, Naam)
Drank (Id, Naam, AlcoholPercentage) //laatste veld is ZEER belangrijk
MixDrank(FK_Mix, FK_Drank)

Zo weet ik altijd dat een FK_ veld een Foreign Key is naar het Id-veld van een andere tabel.

In tegenstelling tot mijn voorbeeld hier gebruik ik normaal wel altijd engelse namen voor tabellen en velden. Ik ben hier strikt in; mn hele ontwikkelomgeving inclusief DB is Engels, alle goeie leerboeken die ik ken zijn engels, dus vooruit maar.

[2]

Ik als lo-fi mysql gebruiker gebruik eigenlijk in de tabelnaam wel underscores, maar in de celnamen weer niet. Ik hou der vooral van om voor de tabelnaam ook de naam van het project of de site te zetten, dus bijvoorbeeld

bakkerbart_broodjes
bakkerbart_beleg
bakkerbart_broodjes_beleg

Zo ben ik bijvoorbeeld bezig met een statestieken script en daarbij heten alle tabellen weer st_hits, st_referers etc. Kun je makkelijk uit elkaar houden welke tabellen horen bij de site en welke bij eventuele modules.

Bij het benoemen van cellen gebruik ik altijd wel de tabelnaam min of meer, vind dat wel overzichtelijk bij joins.

girlName
girlPhonenumber
girlCupsize

etc.

Nederlands of Engels maakt me niet zoveel uit, als het maar duidelijk is. Ik vind het wel iets netter staan om Engelse termen te gebruiken in een omgeving waar alles idd al in het engels is, maar soms lukt dat gewoon niet, als je ineens met 'kuuroorden' te maken hebt bijvoorbeeld.

Wat tomato trouwens zegt over het niet aan variabelen hangen van tabelnamen, daar zit ik inderdaad ook aan te denken, hoewel ik het ergens een beetje twee keer definieren van een variabele vind begin ik er het nut zo langzamerhand wel van in te zien.

[Rense Klinkenberg]

Ik gebruik altijd het volgende:

code:

+---------+
| artists |
+---------+
| ar_id   |
| ar_name |
| ar_age  |
| ar_city |
+---------+

+----------+
|   songs  |
+----------+
| so_id    |
| ar_id    |
| so_title |
| so_year  |
+----------+

Dus veldnamen met daarin de eerste letters van de tabelnaam. Vooral met joins komen de voordelen terug doordat je dezelfde veldnamen joined en je ook niet een zooi 'id' velden terug krijgt waar je in de query weer een alias voor moet gaan maken.

Een bijkomend voordeel is dat de meeste reverse-engine pakketten nu ook de foreign keys zelf kunnen bouwen, omdat MySQL daar niets over weergeeft in een dump

[dusty]

Op woensdag 27 februari 2002 16:15 schreef CrazyD_at_work het volgende:
[..]
PS en ik hoef bij joins dus niet de tabelnaam of alias ervoor te zetten, dus per saldo hoef ik dan toch minder te typen. Goh ben ik toch nog lui

*kuch*, totdat je een keer naar optimalisatie gaat kijken en er opeens achterkomt dat als je een alias gebruikt de query stiekum sneller is.

[TheDane]

oracle naming conventions

[Anoniem: 7195]

Het beste is het gebruik van unieke fieldnames. Dit voorkomt dat je in queries velden moet aliassen. Als je modellen als ORM of Niam gebruikt heb je al die unieke fieldnames. (Dus in de table Users niet 'ID' als key gebruiken maar 'UserID')

Tables prefixen met 't' of 'tbl' zie ik veel, maar ik zie het nut er niet echt van in, daar je in code steevast een tabelnaam kunt onderscheiden van de fieldnames.

Tables prefixen met een afkorting van de groep van tables binnen een applicatie of de applicatie zelf waar de tabel bij hoort kan handig zijn wanneer men veel tabellen heeft. Schroom niet om lange tabelnamen te gebruiken. Als je 150 tables hebt en de namen zijn samengesteld uit 2 letterige afkortingen is het moeilijk zoeken. (Alhoewel documentatie natuurlijk je de weg kan wijzen).

Consistentie is belangrijk. Doe je alles in het engels met 'tbl' prefixes en 'fk' prefixes voor foreign keys bv, doe dat dan ook overal. Dat is net zo belangrijk als de keuze voor die 'tbl' en 'fk' prefixes.

overigens zijn foreign keys etc te halen uit het E/R model van je datamodel. Staar je dus niet blind op het nut van die prefixes, ze kunnen handig zijn, maar dat nut kan overschat worden.

[Anoniem: 3747]

Op donderdag 28 februari 2002 09:37 schreef TheDane het volgende:
oracle naming conventions

Daar zitten enkele elementen in die overeenkomen moet CDM, en anderen die weer totaal anders zijn. Lijkt erop dat als je deze consequent toepast dat er ook goed mee te werken valt
Ergo: de standaard is dat er geen standaard is

[TheDane]

Op donderdag 28 februari 2002 10:46 schreef Patrickje het volgende:

[..]

Daar zitten enkele elementen in die overeenkomen moet CDM, en anderen die weer totaal anders zijn. Lijkt erop dat als je deze consequent toepast dat er ook goed mee te werken valt
Ergo: de standaard is dat er geen standaard is

klopt .. in principe maakt het niet uit welke 'standaard' je gebruikt .. zolang je 't maar consequent doet

[Anoniem: 4255]

Op donderdag 28 februari 2002 02:19 schreef 2 het volgende:
Ik vind het wel iets netter staan om Engelse termen te gebruiken in een omgeving waar alles idd al in het engels is, maar soms lukt dat gewoon niet, als je ineens met 'kuuroorden' te maken hebt bijvoorbeeld.

Kuuroord = Health resort --> HealthResort

Is toch wel te doen