In de databasewereld zijn er een aantal dingen waar iedereen het over eens is. Verhoogd RAM-geheugen is grotendeels gunstig voor DMBS-systemen. Het verspreiden van gegevens en logbestanden op RAID verbetert de prestaties.
Naamgevingsconventies horen daar niet bij.
Dit is een verrassend polariserend onderwerp, met de voorstanders van verschillende methodologieën stevig verankerd in hun standpunten. En zeer vocaal en gepassioneerd in hun verdediging van hetzelfde.
Dit artikel gaat dieper in op enkele van de specifieke conventies en de argumenten aan beide kanten, en probeert voor elk punt een redelijke conclusie te formuleren.
Het grote pluraliseringsdebat
In de kern is dit een eenvoudig onderwerp. Wat is bijvoorbeeld de juiste manier om een tabel een naam te geven die klantgegevens bevat in een relationeel databaseschema? Is het Customer of Customers ?
Argumenten aan beide kanten in overvloed.
Op het eerste gezicht , is het normaal om aan een verzameling objecten in het meervoud te denken. Een groep van meerdere individuen of bedrijven zijn Klanten . Daarom moet een tabel (zijnde een verzameling objecten) in het meervoud worden genoemd. Een individuele rij in die tabel zou een enkele klant zijn .
De ISO/IEC-naamgevingsprincipes, hoewel gedateerd, bevelen meervoudige tabelnamen en enkelvoudige kolomnamen aan.
De meeste SQL Server-systeemtabellen gebruiken meervoudige namen (sysnotifications , sysoperators ), maar dit is niet consistent. Waarom sysproxylogin en niet sysproxylogins ?
In argumenten voor meervoudige tabelnamen wordt naar rijen in een tabel ook verwezen als 'instanties' van een geheel - vergelijkbaar met items in een verzameling. Klanten definieert de hele set; een enkele klant is een instantie van Klanten .
Omgekeerd zijn er veel redenen om enkelvoudige objectnamen te gebruiken.
Hoewel er veel items (of klanten ) in een tabel, kan de tabel zelf als een enkele entiteit worden beschouwd. doos met klanten is geen "dozen met klanten", zelfs als er een groot aantal klanten in zit. Bovendien kan er maar één item - of geen - in de tabel staan, waardoor 'klanten' een verkeerde benaming zijn.
Als u ervoor kiest om de tabelnaam te wijzigen op basis van woordvarianten, kunnen er snel inconsistenties ontstaan. Hoewel veel woorden duidelijk zijn (Klant wordt Klanten , Product wordt Producten ), met andere woorden misschien niet. In dit geval, Persoon kunnen Mensen worden of Personen; een enkelvoud Eland zou er hetzelfde uitzien als de meervoudsvorm, Moose . (Hoewel waarom zou je een tafel met elanden nodig hebben?) Een conventie zoals People.FirstName begint verwarrend onduidelijk te worden.
Als er meerdere talen bij betrokken zijn, wordt de situatie nog erger. Omdat de meervoud van woorden op zoveel manieren kan variëren (klanten, muizen, elanden, kinderen, crises, syllabi, vliegtuigen), hebben niet-moedertaalsprekers extra uitdagingen. Door vast te houden aan enkelvoudige objectnamen wordt dit probleem volledig vermeden.
De Case Convention-vraag
Er is niet hetzelfde enthousiasme bij naamvalconventies als bij pluralisering, maar er worden argumenten aangevoerd voor verschillende opties. Ze omvatten:
- Pascal Case :De eerste letter van elk aaneengeschakeld woord wordt met een hoofdletter geschreven, zoals in:
CustomerOrder -
Kameelkoffer :De eerste letter van het eerste woord is een kleine letter; alle volgende aaneengeschakelde woorden hebben een hoofdletter, zoals in:
customerOrderPascal Case wordt soms beschouwd als een subtype van Camel Case, maar Microsoft maakt over het algemeen een onderscheid tussen de twee.
Voor woorden van minder dan drie tekens wordt aanbevolen om alleen hoofdletters te gebruiken, zoals in
UIofIO. - Onderstreping [C-case] :Woorden worden gescheiden door underscores, zoals in
Customer_Order, ofcustomer_Order– nog meer beslissingen!
Onderzoekers van de Johns Hopkins University hebben onderzoek gedaan naar de efficiëntie van het gebruik van onderstrepingstekens bij het programmeren van objectnamen. Ze ontdekten dat het gebruik van Camel Case (of Pascal Case) de nauwkeurigheid en herkenning van typen verbeterde. Underscores werden veel gebruikt in C-programmering, maar de trend is in de richting van Camel/Pascal Case met recente nadruk op Microsoft- en Java-achtige talen.
Net als bij de andere onderwerpen, volgende een gevestigde conventie is belangrijker dan de selectie van de conventie zelf.
Een extra overweging hierbij is de hoofdlettergevoeligheid van de database. SQL Server-sortering bepaalt deze gevoeligheid met 'CS' (hoofdlettergevoelig) of 'CI' (hoofdlettergevoelig) in de sorteernaam. Bijvoorbeeld:
SQL_Latin1_General_Cp437_CS_AS_KI_WI: Case Sensitive SQL_Latin1_General_Cp437_CI_AS_KI_WI: Case Insensitive
In hoofdlettergevoelige sorteringen, Select * from myTable zou falen tegen het object MyTable . Hierdoor kunnen onderstrepingstekens enigszins de voorkeur hebben om verwarring te voorkomen, maar Intellisense helpt ook om typefouten in de meeste moderne programmeeromgevingen te voorkomen.
Andere overwegingen over de naamgevingsconventie
Het enkelvoud versus meervoud-debat en de grote casusvraag zijn misschien waar de strijd het hevigst is, maar er zijn nog minstens drie andere gebieden om in gedachten te houden bij het overwegen van een naamgevingsconventie.
Vermijd het gebruik van door SQL Server gereserveerde woorden als objectnamen. Dit omvat zowel tabellen als kolommen. Bijvoorbeeld – Gebruiker , Tijd , en Datum zijn gereserveerd. Gereserveerde trefwoorden vereisen mogelijk extra aandacht voor verwijzing (zoals het gebruik van vierkante haken), afhankelijk van de aanroepende toepassing. Dit geldt ook voor ruimtes. Voor spaties in objectnamen zijn aanhalingstekens vereist om te verwijzen.
Dit sluit ook aan bij een andere aanbeveling:precisie. System.CreateDate is veel duidelijker dan System.Date . Een goed ontworpen model stelt de kijker in staat om onmiddellijk het doel van de onderliggende objecten te begrijpen. Wanneer naar identifiers moet worden verwezen als externe sleutels, wees dan vrijgevig in de naam - Customer.CustomerID in plaats van Klant.ID .
Vermijd voor- en achtervoegsels voor tabellen en weergaven , zoals tblTable . Hongaarse notatie (die altijd bedoeld was om het gebruik van variabelen te identificeren) gleed in de algemene naamgevingsconventies van SQL Server, maar wordt op grote schaal bespot. Object-ID's moeten beschrijven wat erin zit, niet het object zelf.
prefixen zijn echter nuttig in SQL Server-ondersteunende objecten , omdat ze de functionele aard van het object beschrijven.
De volgende zijn algemeen aanvaarde voorvoegsels voor SQL Server-objecten:
- IX:Index
- PK:primaire sleutel
- FK:externe sleutel
- CK:Beperking controleren
- DF:standaard
- UQ wordt soms ook gebruikt voor unieke indexen.
Dit model illustreert de hierboven gedefinieerde punten. Het vereist geen uitleg over de aard van de gegevens; Er worden enkelvoudige naamgevingsconventies gebruikt en er zijn duidelijke identificatiegegevens.
Uiteindelijk zijn er voor- en nadelen aan elke kant van het debat over de naamgeving van de conventie. Er is echter één belangrijk punt waar beide partijen het over eens kunnen zijn:ongeacht de genomen beslissingen, wees consistent met de geselecteerde conventie.
Welke SQL-naamgevingsconventies gebruikt u en waarom?