[alg] Descriptive naming - lastig!

[MrBucket]

Ik merk steeds vaker dat het soms erg lastig is om goede namen te vinden voor de symbolen in je programma, d.w.z. voor je classes, methods en members, en database-tabellen en -velden. Ik vind dat duidelijke namen de leesbaarheid van je code enorm verbeteren en dat het echt heel belangrijk is om goede namen te kiezen, maar dat het nog niet zo makkelijk is als dat het op het eerste gezicht lijkt...

Voorbeeld: ik zat laatst te bedenken dat het misschien wel handig is om een cd-databaseje aan te leggen met daarin al mijn muziek-, software-, backup- en film-cds en dvds. En als echte tweakert download je natuurlijk niet 1 van de 10.000 bestaande programma's, nee, die wil je dan zelf bouwen

Zo bedacht ik me bijv:
- dat elke cd of dvd iig een eigen code met volgnummer moest hebben, bijv. MUZ012 of GAM005.
- dat de informatiedrager (cd, cdrw, dvd, ...) los gezien moet worden van hetgeen wat erop staat (een applicatie, spel, muzieknummer), met name omdat een applicatie uit meerdere cd's kan bestaan, en een cd meerdere dingen kan bevatten.

Maar hoe verzin je nu goede benamingen voor de db-tabellen / velden waarin deze informatie opgeslagen moet worden? Ik neem aan dat het gros van de mensen voor Engelse benamingen kiest, dus ik kwam op de volgende benamingen:
- De informatiedrager: Media (tabel)
- Type informatiedrager: Type (veld)
- Volgnummer, code: IndexCode (veld)
- Volgnummer, nummer: IndexNr (veld)
- De inhoud van de cd: Item (tabel, evt. met subclasses: ApplicationItem, MusicItem, etc)

Ik ben niet onverdeeld gelukkig met deze namen. Aan de ene kant zijn ze kort en bondig, maar aan de andere kant is het probleem dat veel van de termen te generiek zijn. Type, Index en Item zijn allemaal namen die je in principe overal voor kunt gebruiken. Maar ik kom ook niet op een betere naamgeving, die kort en bondig is, maar de lading beter dekt...

Hoe gaan jullie om met descriptive naming, hoe zouden jullie het in mijn voorbeeldgeval doen, en hebben jullie misschien nog tips?

--edit--
N.B.: het gaat me hier niet om naming issues zoals prefixes en Hungarian notation (d.w.z: moet het m_iRefCounter, _refCounter of reference_counter worden?), maar meer of je het woord 'ref. counter' moet gebruiken of iets anders).

[ Voor 7% gewijzigd door MrBucket op 18-08-2005 23:47 ]

[NMe]

Eigenlijk de enige tip die ik kan geven is: schroom niet om langere namen te gebruiken voor variabelen/tabellen/velden, mits dat tenminste mogelijk is. Leesbaarheid van je code is belangrijker dan een paar extra toetsaanslagen tijdens het programmeren IMO, en als je een goede editor gebruikt met code completion, dan heb je zelfs dat probleem niet.

In jouw geval zou ik denk ik de media-tabel "Medium" genoemd hebben (tabelnamen zijn altijd enkelvoudig, althans, dat is me altijd geleerd), en de inhoud van een CD zou ik niet "item" noemen maar "content". Type is verder duidelijk genoeg (omdat het Medium.Type is ), evenals IndexCode en IndexNr. Alleen "index" zou ik dan wel weer afkeuren, omdat dat inderdaad nietszeggend is.

Edit: ik heb dit topic even toegevoegd aan P&W FAQ - Algemeen.

[ Voor 5% gewijzigd door NMe op 18-08-2005 23:59 ]

[ripexx]

Wat ik heb gemerkt tijdens het maken van databases is dat je zeker voor veld namen uniforme benamingen moet kiezen. Bijvoorbeeld voor alle primary en foreignkey's ID+tabel of iets dergelijk. Als je dat consequent doet zal je zien dat het werken zer eenvoudig is. Daarnaast is het vaak handig bepaalde veld type een aparte prefix te geven. Zelf ben ik voor tabellen en kolomen geen voor stander van het mixen van upper en lower case namen. Puur en alleen om fouten te voorkomen.

En zoals -NMe- al zegt, zorg dat je tabel namen eigenlijk zelfstandige naamworden zijn en in enkelvoud. Zelf probeer ik in iedergeval altijd Engelstalige benamingen te gebruiken, ook voor bijvoorbeeld variabelen.

[MrBucket]

ripexx schreef op donderdag 18 augustus 2005 @ 23:39:
Wat ik heb gemerkt tijdens het maken van databases is dat je zeker voor veld namen uniforme benamingen moet kiezen. Bijvoorbeeld voor alle primary en foreignkey's ID+tabel of iets dergelijk. Als je dat consequent doet zal je zien dat het werken zer eenvoudig is. Daarnaast is het vaak handig bepaalde veld type een aparte prefix te geven. Zelf ben ik voor tabellen en kolomen geen voor stander van het mixen van upper en lower case namen. Puur en alleen om fouten te voorkomen.

Klopt, dat doe ik ook (en daar zijn ook weer allerlei varianten in te vinden). Maar de reden dat ik die niet in het voorbeeld gebruikt heb, is omdat ik dat een aparte discussie vind, die los staat van het kiezen van duidelijke namen.
Ik zal het ook in de OP zetten.

En zoals -NMe- al zegt, zorg dat je tabel namen eigenlijk zelfstandige naamworden zijn en in enkelvoud. Zelf probeer ik in iedergeval altijd Engelstalige benamingen te gebruiken, ook voor bijvoorbeeld variabelen.

Enkelvoud is een goeie

[.oisyn]

-NMe- schreef op donderdag 18 augustus 2005 @ 23:28:
In jouw geval zou ik denk ik de media-tabel "Medium" genoemd hebben (tabelnamen zijn altijd enkelvoudig, althans, dat is me altijd geleerd),

I don't get that . Ik zie hier een hoop tabelnamen voorbij komen op GoT, en ik erger me altijd aan enkelvoudige tabelnamen. Nou ik lees dat jou dat geleerd is: waarom in hemelsnaam?! . Er staan toch meerdere elementen in? Ergo, je tabel bevat toch media, en niet slechts een medium? En taalkundig klopt het toch ook meer: SELECT * FROM media? Waarom dan het enkelvoud als naam? Een medium is een rij in de tabel, niet de hele tabel.

Om dezelfde reden zijn de namen van containers in m'n code ook altijd meervoud, maar dit schijnt dan weer wat meer common practice te zijn. Hoe noem jij je containers dan? En als je die ook een meervoudige naam geeft, waarom bij tabellen dan niet?

[ Voor 4% gewijzigd door .oisyn op 19-08-2005 01:27 ]

[RobIII]

.oisyn schreef op vrijdag 19 augustus 2005 @ 01:25:
[...]


I don't get that . Ik zie hier een hoop tabelnamen voorbij komen op GoT, en ik erger me altijd aan enkelvoudige tabelnamen. Nou ik lees dat jou dat geleerd is: waarom in hemelsnaam?! . Er staan toch meerdere elementen in? Ergo, je tabel bevat toch media, en niet slechts een medium? En taalkundig klopt het toch ook meer: SELECT * FROM media? Waarom dan het enkelvoud als naam? Een medium is een rij in de tabel, niet de hele tabel.

Om dezelfde reden zijn de namen van containers in m'n code ook altijd meervoud, maar dit schijnt dan weer wat meer common practice te zijn. Hoe noem jij je containers dan? En als je die ook een meervoudige naam geeft, waarom bij tabellen dan niet?

Hear hear! (Sorry -NMe- ).
Degene die deze belachelijke "regel" heeft verzonnen moesten ze ... Anyway. Ik kom inderdaad veel "afgestudeerden" tegen die hetzelfde verhaal vertellen als -NMe-, maar ook ik heb nooit de gein hiervan ingezien. Ik ga dan ook 100% mee met .oisyn in deze.

[matthijsln]

Zolang alle tabelnamen maar consistent enkelvoudig of meervoudig zijn kan ik er mee leven

Ik heb een voorkeur voor enkelvoudige namen, omdat als je een OR mapper gebruikt je natuurlijk geen class "Huizen" gaat maken omdat een object van die class maar één huis voorstelt. Als je dan een class Stad hebt kan je wel mooi een relatie leggen zoals Stad.huizen (een stad heeft meerdere huizen), en van huis naar stad met Huis.stad (huis heeft maar één stad) bijvoorbeeld.

Natuurlijk hoeft je class in je OR mapper die een row uit een tabel voorstelt niet dezelfde naam te hebben als de databasetabel, maar het is wel consistent.

[Genoil]

.oisyn schreef op vrijdag 19 augustus 2005 @ 01:25:
[...]


I don't get that . Ik zie hier een hoop tabelnamen voorbij komen op GoT, en ik erger me altijd aan enkelvoudige tabelnamen. Nou ik lees dat jou dat geleerd is: waarom in hemelsnaam?! . Er staan toch meerdere elementen in? Ergo, je tabel bevat toch media, en niet slechts een medium? En taalkundig klopt het toch ook meer: SELECT * FROM media? Waarom dan het enkelvoud als naam? Een medium is een rij in de tabel, niet de hele tabel.

Om dezelfde reden zijn de namen van containers in m'n code ook altijd meervoud, maar dit schijnt dan weer wat meer common practice te zijn. Hoe noem jij je containers dan? En als je die ook een meervoudige naam geeft, waarom bij tabellen dan niet?

//spuit 11

Nou las je bijvoorbeeld een O/R mapper gebruikt die zowel code als database genereerd adhv 1 XML file, en je noemt daarin je tabel voor medewerkers "employees" ipv "employee", dan krijg je ook classes als Employees, waardan eigenlijk maar 1 medewerker in past. Bij gegenereerde methods wordt het helemaal mooi, krijg je DepartmentPeer::doSelectJoinEmployeess.

Met andere woorden, een tabel bevat wel meerdere records, maar in het werken met een record heb je altijd een record van het type tablename. Je zegt toch ook niet ints *lijstMetGetallen ?

[ Voor 3% gewijzigd door Genoil op 19-08-2005 08:43 ]

[Tomatoman]

MrBucket schreef op donderdag 18 augustus 2005 @ 23:19:
- Type informatiedrager: Type (veld)

SQL:

Type

Hij's groen, dus een reserved word . Type zou ik daarom zeker niet als veldnaam kiezen, dat kan tot vage foutmeldingen in query's leiden.

N.B.: het gaat me hier niet om naming issues zoals prefixes en Hungarian notation (d.w.z: moet het m_iRefCounter, _refCounter of reference_counter worden?), maar meer of je het woord 'ref. counter' moet gebruiken of iets anders).

Ik kom in tabelnamen zelden underscores tegen, maar wel regelmatig hoofdletters (Pascal-style). In dat geval zou je RefCounter of ReferenceCounter gebruiken. Aangezien Ref duidelijk voor Reference staat (geen kans op onduidelijke naamgeving of verwarring) zou ik voor RefCounter kiezen.

Verder ben ik het helemaal met .oisyn eens: tabelnamen zijn logischerwijs meervouden. Dat heeft nog een nevenvoordeel: aangezien veldnamen meestal enkelvoud zijn, herken je in een query de tabelnamen gemakkelijker.

Het roept wel meteen een vraag bij me op: hoe maak je in de naamgeving onderscheid tussen tabellen, views en query's?

[RobIII]

Genoil schreef op vrijdag 19 augustus 2005 @ 08:42:
//spuit 11

Nou las je bijvoorbeeld een O/R mapper gebruikt die zowel code als database genereerd adhv 1 XML file, en je noemt daarin je tabel voor medewerkers "employees" ipv "employee", dan krijg je ook classes als Employees, waardan eigenlijk maar 1 medewerker in past. Bij gegenereerde methods wordt het helemaal mooi, krijg je DepartmentPeer::doSelectJoinEmployeess.

Met andere woorden, een tabel bevat wel meerdere records, maar in het werken met een record heb je altijd een record van het type tablename. Je zegt toch ook niet ints *lijstMetGetallen ?

Ik vind dat geen reden om het zo te doen hoor, eerder een tekortkoming van die O/R mapper.

tomatoman schreef op vrijdag 19 augustus 2005 @ 10:02:
Het roept wel meteen een vraag bij me op: hoe maak je in de naamgeving onderscheid tussen tabellen, views en query's?

I will get shot for this: tbl_MyTable, vw_MyView en qr_MyQuery (en sp_MyStoredProcedure)

[ Voor 19% gewijzigd door RobIII op 19-08-2005 10:32 ]

[NMe]

.oisyn schreef op vrijdag 19 augustus 2005 @ 01:25:
I don't get that . Ik zie hier een hoop tabelnamen voorbij komen op GoT, en ik erger me altijd aan enkelvoudige tabelnamen. Nou ik lees dat jou dat geleerd is: waarom in hemelsnaam?! . Er staan toch meerdere elementen in? Ergo, je tabel bevat toch media, en niet slechts een medium? En taalkundig klopt het toch ook meer: SELECT * FROM media? Waarom dan het enkelvoud als naam? Een medium is een rij in de tabel, niet de hele tabel.

Waarom het ons aangeleerd werd? Geen idee eigenlijk. Mijn leraar vertelde me destijds dat het common practice was, en we het ons dus beter op die manier konden aanleren. Even [google=normaliseren zelfstandig naamwoord enkelvoud] geeft inderdaad genoeg reden om te denken dat het niet alleen door mijn school wordt toegepast.

Ik heb dus werkelijk geen idee waarom het ons geleerd is als het, zoals je zegt, geen common practice is, maar intussen heb ik het mezelf zo aangeleerd, en dus zal ik het waarschijnlijk ook zo blijven doen voor mijn persoonlijke projectjes. Wat ik bij grotere projecten gebruik, dat hangt van de onderling afgesproken standaarden af.

Om dezelfde reden zijn de namen van containers in m'n code ook altijd meervoud, maar dit schijnt dan weer wat meer common practice te zijn. Hoe noem jij je containers dan? En als je die ook een meervoudige naam geeft, waarom bij tabellen dan niet?

Hmm, mijn containers zijn ook altijd meervoud, omdat het daar gewoon duidelijker is. Bij tabelnamen kan er volgens mij niet echt verwarring ontstaan, dus daar kun je wel enkelvoudige namen gebruiken. Waarom ik zo programmeer? Gevoelsmatig.

[RobIII]

-NMe- schreef op vrijdag 19 augustus 2005 @ 10:31:
Wat ik bij grotere projecten gebruik, dat hangt van de onderling afgesproken standaarden af.
[...]
Waarom ik zo programmeer? Gevoelsmatig.

Daar gaat het uiteindelijk natuurlijk ook om. Als je zelf (of je team) er maar uit kan komen is er weinig aan de hand denk ik.

offtopic:
Woooo, ik zet net m'n icon effe op de PW-meeting countdown. Da's effe schrikken! Nog 15 dagen.... Ik dacht (gevoelsmatig ) nog langer. Zal toch eens die spamrun gaan doen

[ Voor 22% gewijzigd door RobIII op 19-08-2005 10:35 ]

[P_de_B]

Ik zou ook liever de tabelnamen in het meervoud zien. We zijn helaas in het verleden niet altijd consitent geweest maar ik heb het liefst de tabelnamen in het meervoud. Met normaliseren heeft de naamgeving natuurlijk weinig van doen.

In mijn beleving bevat de Customers tabel meerdere klanten, dus meervoud. Waar ik dan wel een hekel aan heb is om extra inhoud aan de naam van een kolom te geven, bijvoorbeeld het datatype of de tabelnaam herhaald. Bijvoorbeeld in de tabel Customers de kolom Firstname customerFirstName te noemen. Tuurlijk is het een 'Customer' hij zit in de Customer tabel.

Er wat -NMe- ook al zei, kijk niet op een letter meer of minder bij naamgeving van variabelen en methodes. Duidelijkheid is inderdaad belangrijker dan het besparen van een toetsaanslag.

[Michali]

Het is idd fijner om meervoud voor tabel namen te gebruiken. Al is het dan puur om in een query de tabelnamen gemakkelijker van de kolomnamen te kunnen onderscheiden. Maar enkelvoud valt ook wel te verdedigen. Dat is de naam meer een beschrijving van wat er in gaat en niet wat het in zijn geheel bevat.

[RobIII]

P_de_B schreef op vrijdag 19 augustus 2005 @ 10:38:
In mijn beleving bevat de Customers tabel meerdere klanten, dus meervoud. Waar ik dan wel een hekel aan heb is om extra inhoud aan de naam van een kolom te geven, bijvoorbeeld het datatype of de tabelnaam herhaald. Bijvoorbeeld in de tabel Customers de kolom Firstname customerFirstName te noemen. Tuurlijk is het een 'Customer' hij zit in de Customer tabel.

Niet helemaal mee eens, maar die discussie wil ik nu niet (weer) oplaaien.
Toch een illustratie:

Ik heb een tabel Customers (tbl_Customers) met daarin cus_id en cus_name, cus_cnt_id,...
Ik heb een tabel Countries (tbl_Countries) met daarin cnt_id, cnt_name, ...
Als ik nu een join wil op die 2 tabellen:

SQL:

Select * from tbl_Customers
Inner join tbl_Countries on cus_cnt_id = cnt_id
Where...

Had ik die prefixen niet gehad:

SQL:

Select * from Customers
Inner join Countries on tbl_Customers.cnt_id = tbl_Countries.cnt_id
Where...

In dit geval (los van dat je select * gebruikt) vind ik het niet zo'n ramp om die tabel namen over te nemen. Maar als ik een koppeltabel heb met Customers en Countries:
tbl_CustomerCountries met de velden cc_cus_id, cc_cnt_id dan zie je meteen welk veld wat is. Had ik die prefixes niet: CustomerCountries met id en id ? Nu had ik deze 2 velden wel een eigen naam kunnen geven, maar nu gebruik ik gewoon consistent mijn prefixes en hoef ik niet na te denken over namen voor de velden in de koppeltabel en weet ik meteen (aan de naam van de velden) in bijv. een query dat bijv. het veld cc_cus_id uit de tabel CustomerCountries komt (vanwege cc_ ) en dat die corrospondeert met cus_id uit de tabel Customers (vanwege cus_ ). Tevens creeër je op deze manier relatief unieke veldnamen door al je tabellen en kan er zelden verwarring ontstaan. Het heeft ook vast nadelen, maar ik prefereer dit (na jaren dit erin gestampt te hebben gekregen hoor!) dan weer wel.

Edit: En natuurlijk is het netter om ook in de eerste Select statement uit deze post toch de tabelnamen ervoor te gooien bij die join.

[ Voor 7% gewijzigd door RobIII op 19-08-2005 10:51 ]

[P_de_B]

Ik vind de makkelijkheid van het schrijven van queries nu niet een erg sterk argument Je kun ook een alias gebruiken, buiten het feit dat je vaak de id's van een koppeltabel niet meeneemt.

Daarnaast vind in cc_cnt_id achtige omschrijvingen ook niet erg prettig moet ik zeggen. Wat is nu een cc_cnt_id? Waarom niet CustomersCountryId?

[RobIII]

P_de_B schreef op vrijdag 19 augustus 2005 @ 10:55:
Ik vind de makkelijkheid van het schrijven van queries nu niet een erg sterk argument

Eensch

P_de_B schreef op vrijdag 19 augustus 2005 @ 10:55:
Je kun ook een alias gebruiken, buiten het feit dat je vaak de id's van een koppeltabel niet meeneemt.

Eensch, maar een alias vind ik niet altijd even duidelijk...

P_de_B schreef op vrijdag 19 augustus 2005 @ 10:55:
Daarnaast vind in cc_cnt_id achtige omschrijvingen ook niet erg prettig moet ik zeggen. Wat is nu een cc_cnt_id? Waarom niet CustomersCountryId?

Zolang je weet dat cc = CustomerCountries en cnt = Country (en dus cc_cus_id -> cc = CustomerCountries en cus = Customers) is het wel handig. Het is hierbij inderdaad wel kunst om de juiste "abbreviations" te vinden zodat ze toch nog enigszins makkelijk lezen. Zo vind ik cus_ nogal makkelijk, maar inderdaad cnt_ kan al verwarrend worden (laat staat cc_). Helaas is dit zoals het er bij mij jaren geleden is in gestampt en ik kan me dan ook wel inleven in -NMe-'s situatie. Dit soort dingen is erg moeilijk af te leren als je ze eenmaal gewend bent. Databases zonder mijn "vertrouwde prefixes" zien er zo raar uit
Toch is dit een prima werkmethode voor databases met niet achterlijk veel tabellen e.d. Zeker voor een gemiddeld web-siteje (met dus maar een paar tabellen doorgaans) is dit erg handig (voor mij dan). Voor de "joekels" van databases heb ik dit overigens nooit gebruikt, daarbij ben ik altijd meegegaan met "de rest". Het ziet er dan dus alleen "raar" uit voor mij

[ Voor 19% gewijzigd door RobIII op 19-08-2005 11:02 ]

[P_de_B]

RobIII schreef op vrijdag 19 augustus 2005 @ 10:59:
Databases zonder mijn "vertrouwde prefixes" zien er zo raar uit

Natuurlijk is het ook een heel persoonlijk iets, maar als ik nu bij jullie zou komen werken, of iemand anders moet eens iets aan de db doen is het erg zoeken. Maar goed, ieder z'n eigen.

[Tomatoman]

Voor de aardigheid heb ik gekeken hoe de tabellen heten in de bekendste database ter wereld: Noordenwind (Northwind).



Alle tabelnamen in meervoud dus.

[RobIII]

P_de_B schreef op vrijdag 19 augustus 2005 @ 11:02:
[...]

Natuurlijk is het ook een heel persoonlijk iets, maar als ik nu bij jullie zou komen werken, of iemand anders moet eens iets aan de db doen is het erg zoeken.

Dat valt reuze mee. Ik zal eens kijken of ik niet 1 of andere DB kan posten.
Edit: Kan zo snel geen vinden die ik hier "zomaar" kan posten...Ik zal vanavond nog wel eens even zuhause zoeken als ik tijd heb.

[ Voor 16% gewijzigd door RobIII op 19-08-2005 11:10 ]

[Trinsec]

RobIII schreef op vrijdag 19 augustus 2005 @ 10:48:
[...]
Ik heb een tabel Customers (tbl_Customers) met daarin cus_id en cus_name, cus_cnt_id,...
Ik heb een tabel Countries (tbl_Countries) met daarin cnt_id, cnt_name, ...
Als ik nu een join wil op die 2 tabellen:

SQL:

Select * from tbl_Customers
Inner join tbl_Countries on cus_cnt_id = cnt_id
Where...

Had ik die prefixen niet gehad:

SQL:

Select * from Customers
Inner join Countries on tbl_Customers.cnt_id = tbl_Countries.cnt_id
Where...

Wat ik altijd doe:

SQL:

Select * from Customers
Inner join Countries USING (cnt_id)
Where...

In dit geval vind ik het best geweldig om dezelfde fieldnamen te gebruiken. Het is duidelijk dat ze bij elkaar horen en USING vind ik een erg handige manier t.o.v. ON table1.id=table2.id.

[.oisyn]

matthijsln schreef op vrijdag 19 augustus 2005 @ 08:35:
Ik heb een voorkeur voor enkelvoudige namen, omdat als je een OR mapper gebruikt je natuurlijk geen class "Huizen" gaat maken omdat een object van die class maar één huis voorstelt.

Dat vind ik dan een tekortkoming in de OR mapper. Zeker de opmerking die Genoil maakte in de post erna:

Bij gegenereerde methods wordt het helemaal mooi, krijg je DepartmentPeer::doSelectJoinEmployeess.

Right, gewoon maar even een s erachter plakken om er meervoud van te maken, dat is mooi. Werkt ook vooral goed bij woorden als matrix, vertex en index

Nou heb ik geen ervaring met OR mappers, maar dit lijkt me een van de dingen die configureerbaar moeten zijn. Zeker omdat je in sommige gevallen met een bestaande database andere namen wil dan de tabelnamen omdat die gewoon niet stroken met je programmeerstyle. Stel ik gebruik een database van RobIII, ik moet er niet aan denken dat mijn klasse tbl_Customer gaat heten. Of namen met tekens erin die niet voldoen aan de specs van je programmeertaal. Ergo, als je dat niet kunt configureren dan is je OR mapper crappy

[Tomatoman]

Is je als tabelnaam Huis kiest (enkelvoud dus), maakt die OR-mapper er bij een genereerde method ook een fijne naam van:

DepartmentPeer::doSelectJoinHuiss

Is dat even fijn, zo'n OR-mapper.

[TheRookie]

RobIII schreef op vrijdag 19 augustus 2005 @ 10:59:[..] Zolang je weet dat cc = CustomerCountries en cnt = Country (en dus cc_cus_id -> cc = CustomerCountries en cus = Customers) is het wel handig. Het is hierbij inderdaad wel kunst om de juiste "abbreviations" te vinden zodat ze toch nog enigszins makkelijk lezen. Zo vind ik cus_ nogal makkelijk, maar inderdaad cnt_ kan al verwarrend worden (laat staat cc_).
[..]
Voor de "joekels" van databases heb ik dit overigens nooit gebruikt, daarbij ben ik altijd meegegaan met "de rest". Het ziet er dan dus alleen "raar" uit voor mij

Dit is 'helaas' wel de naming convention die Exact lijkt te hanteren in de eSynergy/Globe database, érg "leuk" uitzoekwerk als je zelf queries wil draaien op de data

[ Voor 34% gewijzigd door TheRookie op 19-08-2005 12:44 . Reden: betere quote ]

[RedRose]

Ook logisch gezien horen tabelnamen in meervoud te zijn. Als je één record in de tabel had zitten, dan niet. Maar dan heb je ook geen tabel nodig.

Welke OR-mapper is dat?

[RobIII]

TheRookie schreef op vrijdag 19 augustus 2005 @ 12:43:
[...]

Dit is 'helaas' wel de naming convention die Exact lijkt te hanteren in de eSynergy/Globe database, érg "leuk" uitzoekwerk als je zelf queries wil draaien op de data

En zo zijn er nog wel meer meen ik me te herinneren. Heel gek of moeilijk is het ook niet. Het is soms gewoon wat meer typewerk (tbl_ enzo prefixes) en soms wat minder (in je queries hoef je je tabelnamen niet te vermelden).En je maakt me niet wijs dat je wél een "gewone" DB kunt begrijpen c.q. lezen en een DB met die prefixes niet. Dat gaat er niet in bij mij.

[TeeDee]

Gevoelsmatig zeg ik voor Tabelnamen toch echt meervoud.
Mijn collega zegt dat het om 1 entiteit gaat, dus enkelvoud. Hij heeft tijdens zijn opleiding jaren terug ook 'geleerd' dat het enkelvoud moet zijn.

Tegenargument (welke reeds is gezegd) is dat er meerdere "records" in 1 tabel zitten.
Zoals de grootste filosoof van Nederland ooit eens zei: "Elk voordeel heb zijn nadeel".

Even gauw in de SQL-dev van mijn collega gekeken. Alles enkelvoud. (Behalve t_Postcodes)

Naming conventions die we wel altijdbijna altijd hanteren zijn:
tb_Naam, vw_Naam, sproc_Naam, tr_Naam etc.

Persoonlijk vind ik het het netst om zo min mogelijk een cryptisch iets mee te geven. Liever iets langer dan dat je 1 jaar later niet meer op het eerste gezicht kan zien wat wat doet.
(Dit slaat imho niet alleen op Databanken, maar op code in het algemeen.)

edit:
sp >> sproc

@P_de_B hieronder: Ik weet het. Tikfoutje, moet alleen vaker de handel even refreshen.

[ Voor 17% gewijzigd door TeeDee op 19-08-2005 13:36 ]

[P_de_B]

sp_ prefixes zijn uit den boze. Voor deze sp's wordt eerst in de master database gekeken of ze bestaan.

[.oisyn]

Hier trouwens een screenshot van EfBe's LLBLGen Pro, een O/R mapper generator:


De screenshot laat duidelijk zien dat de entiteitnaam Customer is, en die is gemapped op de tabelnaam Customers. Dus dat O/R mappers het niet kunnen is een onzinargument

[RedRose]

In LLBLGen zijn sowieso de meeste namen (Tables / Fields / Relations etc) aanpasbaar.

edit: inderdaad, de DAL die wordt gegeneerd werkt met entiteitnamen (de types in de DAL) die default enkelvoud zijn, wat dan volgens mij ook wel wer een standaard is voor types.

[ Voor 52% gewijzigd door RedRose op 19-08-2005 14:02 ]

[RobIII]

P_de_B schreef op vrijdag 19 augustus 2005 @ 13:32:
sp_ prefixes zijn uit den boze. Voor deze sp's wordt eerst in de master database gekeken of ze bestaan.

Zie ook http://msdn.microsoft.com...tedb/cm_8_des_07_7yw5.asp daarvoor.

[Anoniem: 50068]

Wellicht ten overvloede, maar mij is op HBO Hogere Informatica altijd geleerd dat tabelnamen meervoud horen te zijn.

(--edit: dat was ongeveer 2 jaar geleden dacht ik)

[ Voor 21% gewijzigd door Anoniem: 50068 op 19-08-2005 14:09 ]

[TheRookie]

RobIII schreef op vrijdag 19 augustus 2005 @ 13:13:
[...]
En je maakt me niet wijs dat je wél een "gewone" DB kunt begrijpen c.q. lezen en een DB met die prefixes niet. Dat gaat er niet in bij mij.

Dat zal je mij ook niet zien zeggen; wat wel zo is, is dat het gebruik van afkortingen (en/of nondescriptive tabel/kolom namen) de leesbaarheid wel degelijk beïnvloeden.

En áls men dan de tabelnaam ook in de velden van die tabel terug wil laten komen, wees dan concequent en niet de ene helft van een tabel niet en de andere helft wel....

[Anoniem: 50068]

TheRookie schreef op vrijdag 19 augustus 2005 @ 14:26:
[...]
En áls men dan de tabelnaam ook in de velden van die tabel terug wil laten komen, wees dan concequent en niet de ene helft van een tabel niet en de andere helft wel....

Voortschrijdend inzicht leidt tot dergelijke situaties...
Het is dan erg veel werk om alle oude velden/tabellen om te nummeren, maar toch wil je (vanaf het punt dat je 't inzicht verkrijgt) alles netjes houden/maken voor toekomstige velden/tabellen.

[TheRookie]

Kan ik me voorstellen, maar het laat onverlet dat het voor mij als "eindgebruiker" erg lastig is ...

[ Voor 8% gewijzigd door TheRookie op 19-08-2005 15:25 ]

[TeeDee]

.oisyn schreef op vrijdag 19 augustus 2005 @ 13:42:
Hier trouwens een screenshot van EfBe's LLBLGen Pro, een O/R mapper generator:
[afbeelding]

De screenshot laat duidelijk zien dat de entiteitnaam Customer is, en die is gemapped op de tabelnaam Customers. Dus dat O/R mappers het niet kunnen is een onzinargument

Bedankt daarvoor.
Zoals ik al zei heeft mijn collega het over één entiteit. De entiteit is bijv. de Customer, in de "verzamelbak" tbl_Customers.

Denk dat hij het e.e.a door elkaar haalt omdat het vrijdag is .

[JJvG]

Mij is ook altijd geleerd de tabelnamen in enkelvoud te doen (HBO, 5 jaar geleden). Persoonlijk maakt het me niet zo heel veel uit, als het maar consequent is: of enkelvoud, of meervoud, maar niet door elkaar. Daarnaast kan ik me ook mateloos ergeren aan Engelse en Nederlandse namen door elkaar (bijvoorbeeld tblGebruikers en tblGroups o.i.d).

Volgens mij is de reden om voor enkelvoud te kiezen dat de query's door het gebruik van enkelvoud eenvoudiger leesbaar zijn (Customer.Name e.d. i.t.t. Customers.Name)

[matthijsln]

OR mappers zijn natuurlijk geen probleem, het zou wel een erg slechte zijn indien je een entiteit niet anders kan noemen dan de tabelnaam of niet zelf de naam van een relatie kan kiezen.

Alleen door het gebruik daarvaan heb ik wel een voorkeur voor enkelvoudige namen. Het is toch wel duidelijk dat er meerdere records in een tabel zitten. In plaats van voor het onderscheid tussen tabelnamen en kolomnamen gebruik ik het verschil tussen enkelvoud en meervoud liever voor de naam van iets-op-N relaties (meervoud) en de naam van de entiteit (enkelvoud).

[Annie]

tomatoman schreef op vrijdag 19 augustus 2005 @ 10:02:
Dat heeft nog een nevenvoordeel: aangezien veldnamen meestal enkelvoud zijn, herken je in een query de tabelnamen gemakkelijker.

Als je in een query het verschil tussen enkelvoud en meervoud nodig hebt om de tabelnamen te herkennen, dan is er iets serieus mis met je

Ik moet zeggen dat ik al 3 keer van naming methode ben gewijzigd. De eerste methode die ik gebruikte, leek veel op die van RobIII. Ik moet zeggen dat ik deze methode nu niet meer kan verdragen: onleesbaar, zinloos, lelijk en.., uh, had ik al zinloos gezegd?
Tweede methode was met meervoud voor tabelnamen. Ik moet zeggen dat dat voor mij nog steeds het meest natuurlijk overkomt. Met name wanneer je de db als uitgangspunt neemt en continu in de QA (in het geval van mssql) bezig bent.
Echter ik gebruik tegenwoordig enkelvoud. Dat is de afspraak die we hebben gemaakt op onze afdeling en ik heb daar geen moeite mee. De db is niet echt het uitgangspunt, dat is bij ons de applicatie. En om nu telkens bij het genereren van een DAL, de tabelnamen te vertalen naar een (correcte) entiteit in de DAL, vind ik zo onzinnig. Dus, dan maar enkelvoud en de namen 1-op-1 overnemen.

Oh ja, die naamgeving die RobIII gebruikt, is dus echt onzinnig en onleesbaar. Of had ik dat al gezegd

[drm]

Annie:
Dat is de afspraak die we hebben gemaakt op onze afdeling en ik heb daar geen moeite mee.

Agreed. 't Is imo maar net wat je afspreekt. Als we hier morgen zouden beslissen (afgezien van 't feit dat we doorgaans weinig op zaterdag beslissingen over dat soort dingen maken) om voortaan meervoudstabelnamen te gebruiken zal ik daar geen moment van wakker liggen. 't Is zo'n eindeloos zinloze discussie, net als CamelCased en under_scores, wel of geen hoofdletters bij acroniemen (XmlDocument, XMLDocument), de enkelvoudige PK's van tabellen altijd "id" noemen, of er "_id" of 'ID', achter zetten, of 'Id' ervoor (ja die zijn er ook), koppeltabellen naamgeven op basis van parent/child relaties, of alfabetisch, of gewoon omdat het lekkerder klinkt.

Lekker belangrijk, als we daarover nou even niet zo moeilijk doen, kunnen we weer over nuttige dingen na gaan denken

[SuperRembo]

tomatoman schreef op vrijdag 19 augustus 2005 @ 11:02:
Voor de aardigheid heb ik gekeken hoe de tabellen heten in de bekendste database ter wereld: Noordenwind (Northwind).

[afbeelding]

Alle tabelnamen in meervoud dus.

Een tabelnaam met een trema er in. Dat lijkt me geen aanbeveling.

[TeeDee]

@Annie:
Jij vind tbl_ etc. etc. onzinnig en onleesbaar? Bij mij zit het er zo ingebakken dat ik van tbl_ automagisch Table maak.

Verder ben ik het helemaal eens met je wat betreft de afspraken die je maakt.

[Annie]

TeeDee schreef op zaterdag 20 augustus 2005 @ 06:39:
@Annie:
Jij vind tbl_ etc. etc. onzinnig en onleesbaar? Bij mij zit het er zo ingebakken dat ik van tbl_ automagisch Table maak.

Bijna . Ik vind tbl_ onzinnig en cnt_cus_ID (and the likes) onleesbaar.

[EfBe]

ik kwam laatst een db tegen met 'fld_' prefixes voor ieder field en 'tbl_' uiteraard voor iedere table. Tja, stel je voor dat je in een query denkt... is het een table, of een field? Gelukkig dat de prefix er was!

[MrBucket]

Ik merk dat de inhoud van dit topic meer een richting ingaat waar ik persoonlijk toch minder in ben geinteresseerd, namelijk die van prefixes, vervoegingen en notatie. Alhoewel dit ook een heel valide discussiepunt is, denk ik dat die zaken toch redelijk los beschouwd kunnen worden van de zelfstandig naamwoorden en werkwoorden die in tabel-, class-, method- en membervariable-namen gebruikt worden.

Nu is het misschien ook wel lastig om richtlijnen te geven voor de zelfstandig naamwoorden en werkwoorden die je erin verwerkt, maar toch vraag ik me af: hoe krijg je duidelijke termen in je symbolen?

Ik neem aan dat de meest voor de hand liggende methode is om deze uit de opdrachtomschrijving te destilleren. Maar dat neemt niet weg dat deze vaak niet duidelijk genoeg is om alle termen eruit te kunnen halen. Ook zul je vanuit het oogpunt van de ontwikkelaar een aantal termen moeten introduceren die alleen in de context van je sourcecode bestaan (en waar de eindgebruiker nooit mee te maken zal krijgen).

Hoe voorkom je dat je te algemene termen gebruikt (zoals item, element, index, type, etc.) Hebben jullie een vaste lijst van mogelijke woorden, introduceren jullie zelf nieuwe termen (zoals een hashmap bijvoorbeeld 'buckets' heeft - dit is een metafoor voor de functionaliteit die zo'n ding heeft in de hashmap), of lossen jullie het op een andere manier op?

[EfBe]

je moet er niet zo mee zitten. Het enige wat telt is dat je naam vertelt wat het voorstelt, niet meer en ook niet minder. Dus als jij een functie hebt die een zekere waarde ophaalt EN deze format, dan moet je die functie dus noemen GetAndFormatValue, en niet GetValue, of FormatValue, want de functie doet meer dan dat.

Ben je in een functie veelvuldig met een aantal verschillende dingen bezig van hetzelfde type, bv entities, dan heb je in een loop bv een variable die 'currentEntity' heet, zodat je weet wat de huidige is in die loop.

Het enige uitgangspunt voor je naam is: iemand die de code leest en die naam ziet moet METEEN weten wat voor waarde / functionaliteit die naam representeert. Zodra je dus een naam bedenkt moet die daaraan toetsen.

En nee, een functie met een naam langer dan 10 characters is niet slecht, het enige wat telt is dat de naam vertelt wat hij representeert. Als je daar 40 characters voor nodig hebt, c'est la vie.