I databasvärlden finns det några saker som man är allmänt överens om. Ökat RAM-minne är till stor del fördelaktigt för DMBS-system. Att sprida ut data och loggfiler på RAID förbättrar prestandan.
Namnkonventioner är inte en av dessa saker.
Detta är ett överraskande polariserande ämne, med förespråkarna för olika metoder fast förankrade i sina ståndpunkter. Och väldigt högljudda och passionerade i deras försvar av detsamma.
Den här artikeln kommer att fördjupa sig i några av de specifika konventionerna och argumenten från båda sidor, samtidigt som man försöker presentera en rimlig slutsats för varje punkt.
Den stora pluraliseringsdebatten
I grunden är detta ett enkelt ämne. Till exempel, vad är det korrekta sättet att namnge en tabell som innehåller kundinformation i ett relationsdatabasschema? Är det Customer eller Customers ?
Det finns många argument på båda sidor.
Vid första anblicken , är det naturligt att tänka på en samling objekt i plural. En grupp med flera individer eller företag skulle vara kunder . Därför bör en tabell (som är en samling objekt) namnges i plural. En enskild rad i den tabellen skulle vara en enda kund .
ISO/IEC-namnprinciperna, även om de är daterade, rekommenderar pluraliserade tabellnamn och singularkolumnnamn.
De flesta SQL Server-systemtabeller använder pluralnamn (sysnotifications , sysoperatorer ), men detta är inkonsekvent. Varför sysproxylogin och inte sysproxylogins ?
I argument för plural tabellnamn hänvisas rader i en tabell också till som "instanser" av en helhet - liknande objekt i en samling. Kunder definierar hela uppsättningen; en enda kund är en instans av Kunder .
Omvänt finns det många skäl att använda singulära objektnamn.
Även om det kan finnas många artiklar (eller kunder). ) i en tabell kan själva tabellen betraktas som en enda enhet. låda med kunder är inte "en låda med kunder", även om den har ett stort antal kunder inuti. Dessutom kan det bara finnas en artikel – eller ingen – i tabellen, vilket gör "kunder" till en felaktig benämning.
Om du väljer att ändra tabellnamnet baserat på ordvarianter kan inkonsekvenser snabbt uppstå. Medan många ord kommer att vara enkla (Kund blir Kunder , Produkt blir Produkter ), andra ord kanske inte är det. I det här fallet, Person kan bli Människor eller Personer; en singular älg skulle se ut som dess pluralform, Älg . (Men varför skulle du behöva ett bord med älgar?) En konvention som People.FirstName börjar bli förvirrande otydligt.
Om flera språk är inblandade blir situationen ännu värre. Eftersom pluralisering av ord kan variera på så många sätt (kunder, möss, älgar, barn, kriser, kursplaner, flygplan) har personer som inte är modersmål ytterligare utmaningar. Att hålla sig till singulara objektnamn undviker detta problem helt.
Case Convention Question
Det finns inte samma glöd med fallkonventioner som med pluralisering, men argument för flera olika alternativ. De inkluderar:
- Pascal-fodral :Den första bokstaven i varje sammanfogat ord är versal, som i:
CustomerOrder -
Kamelfodral :Första bokstaven i det första ordet är gemen; alla efterföljande sammanlänkade ord har en stor första bokstav, som i:
customerOrderPascal Case anses ibland vara en undertyp av Camel Case, men Microsoft skiljer i allmänhet mellan de två.
För ord mindre än tre tecken, rekommenderas det att endast använda versaler, som i
UIellerIO. - Understreck [C-fall] :Ord separeras med understreck, som i antingen
Customer_Order, ellercustomer_Order– ännu fler beslut!
Forskare vid Johns Hopkins University genomförde en studie om effektiviteten av att använda understreck i programmering av objektnamn. De fann att användningen av Camel Case (eller Pascal Case) förbättrade skrivnoggrannheten och igenkänningen. Understreck användes i stor utsträckning i C-programmering, men trenden går mot Camel/Pascal Case med den senaste tidens tonvikt på Microsoft- och Java-språk.
Som med de andra ämnena, följer en etablerad konvention är viktigare än urvalet av själva konventionen.
Ett ytterligare övervägande här är skiftlägeskänsligheten i databasen. SQL Server-sortering bestämmer denna känslighet med 'CS' (skiftlägeskänslig) eller 'CI' (skiftlägeskänslig) i sorteringsnamnet. Till exempel:
SQL_Latin1_General_Cp437_CS_AS_KI_WI: Case Sensitive SQL_Latin1_General_Cp437_CI_AS_KI_WI: Case Insensitive
I skiftlägeskänsliga sorteringar Select * from myTable skulle misslyckas mot objektet MyTable . Detta kan göra understreck något att föredra för att förhindra förvirring, men Intellisense hjälper också till att eliminera skrivfel i de flesta moderna programmeringsmiljöer.
Andra hänsyn till namnkonventionen
Singular vs. Plural Debate and the Great Case Question kan vara där striden är som hårdast, men det finns åtminstone ytterligare tre områden att tänka på när man överväger en namnkonvention.
Undvik att använda reserverade SQL Server-ord som objektnamn. Detta inkluderar både tabeller och kolumner. Till exempel – Användare , Tid och Datum är reserverade. Reserverade sökord kan kräva ytterligare försiktighet att referera (som att använda hakparenteser) beroende på den anropande applikationen. Detta gäller även utrymmen. Mellanslag i objektnamn kräver citattecken för att referera.
Detta hänger också ihop med en annan rekommendation – precision. System.CreateDate är mycket tydligare än System.Date . En väldesignad modell låter betraktaren omedelbart förstå syftet med de underliggande objekten. När någon identifierare ska hänvisas till som främmande nycklar, var liberal i namnet – Customer.CustomerID istället för Kund.ID .
Undvik prefix och suffix för tabeller och vyer , till exempel tblTable . Ungersk notation (som alltid var avsedd att identifiera variabel användning) gled in i vanliga SQL Server-namnkonventioner, men det hånas allmänt. Objektidentifierare ska beskriva vad som finns i, inte själva objektet.
Men prefix är användbara i SQL Server-stödjande objekt , eftersom de beskriver objektets funktionella natur.
Följande är allmänt accepterade prefix för SQL Server-objekt:
- IX:Index
- PK:Primär nyckel
- FK:Utländsk nyckel
- CK:Kontrollera begränsning
- DF:Standard
- UQ används ibland även för unika index.
Denna modell illustrerar de ovan definierade punkterna. Det kräver ingen förklaring om uppgifternas natur; singular namnkonventioner används och tydliga identifierare finns på plats.
I slutändan finns det fördelar och nackdelar med varje sida av konventionens namndebatt. Det finns dock en viktig punkt som båda sidor kan komma överens om:oavsett vilka beslut som fattas, var konsekventa med den valda konventionen.
Vilka SQL-namnkonventioner använder du och varför?