I databaseverdenen er der nogle ting, der er universelt enige om. Øget RAM er i høj grad gavnlig for DMBS-systemer. Udbredelse af data og logfiler på RAID forbedrer ydeevnen.
Navnekonventioner er ikke en af disse ting.
Dette er et overraskende polariserende emne, hvor fortalere for forskellige metoder er solidt forankret i deres holdninger. Og meget vokale og passionerede i deres forsvar for det samme.
Denne artikel vil dykke ned i nogle af de specifikke konventioner og argumenterne fra begge sider, mens vi forsøger at præsentere en rimelig konklusion for hvert punkt.
Den store pluraliseringsdebat
I sin kerne er dette et simpelt emne. For eksempel, hvad er den korrekte måde at navngive en tabel, der indeholder kundeoplysninger i et relationsdatabaseskema? Er det Customer eller Customers ?
Der er mange argumenter på begge sider.
Ved første øjekast , er det naturligt at tænke på en samling af objekter i flertal. En gruppe af flere enkeltpersoner eller virksomheder ville være kunder . Derfor bør en tabel (der er en samling af objekter) navngives i flertal. En individuel række i den tabel ville være en enkelt kunde .
ISO/IEC-navngivningsprincipperne anbefaler, selv om de er dateret, pluraliserede tabelnavne og entalskolonnenavne.
De fleste SQL Server-systemtabeller bruger flertalsnavne (sysnotifications , sysoperatorer ), men dette er inkonsekvent. Hvorfor sysproxylogin og ikke sysproxylogins ?
I argumenter for tabelnavne i flertal refereres rækker i en tabel også som 'instanser' af en helhed - svarende til elementer i en samling. Kunder definerer hele sættet; en enkelt kunde er en forekomst af Kunder .
Omvendt er der mange grunde til at bruge enkeltstående objektnavne.
Selvom der kan være mange varer (eller kunder). ) i en tabel kan selve tabellen betragtes som en enkelt enhed. kasse med kunder er ikke "en kasse med kunder", selvom den har et stort antal kunder indeni. Derudover kan der kun være én genstand – eller ingen – inde i bordet, hvilket gør "kunder" til en forkert betegnelse.
Hvis du vælger at ændre tabelnavnet baseret på ordvarianter, kan der hurtigt opstå uoverensstemmelser. Mens mange ord vil være ligetil (Kunde bliver Kunder , Produkt bliver Produkter ), andre ord er det måske ikke. I dette tilfælde Person kunne blive Mennesker eller Personer; en ental Elg ville se det samme ud som dens flertalsform, Elg . (Selvom hvorfor skulle du bruge et bord med elge?) En konvention såsom People.FirstName begynder at blive forvirrende uklart.
Hvis flere sprog er involveret, bliver situationen endnu værre. Fordi pluralisering af ord kan variere på så mange måder (kunder, mus, elge, børn, kriser, pensum, fly), har ikke-modersmålstalere yderligere udfordringer. Ved at holde sig til ental objektnavne undgås dette problem helt.
Sagens konventionsspørgsmål
Der er ikke den samme inderlighed med case-konventioner som med pluralisering, men der argumenteres for flere forskellige muligheder. De omfatter:
- Pascal-etui :Det første bogstav i hvert sammenkædet ord er stort, som i:
CustomerOrder -
Kameletui :Det første bogstav i det første ord er små bogstaver; alle efterfølgende sammenkædede ord har et stort første bogstav, som i:
customerOrderPascal Case betragtes nogle gange som en undertype af Camel Case, men Microsoft skelner generelt mellem de to.
For ord med mindre end tre tegn anbefales det kun at bruge store bogstaver, som i
UIellerIO. - Understregning [“C”-case] :Ord adskilles med understregninger, som i enten
Customer_Order, ellercustomer_Order– endnu flere beslutninger!
Forskere ved Johns Hopkins University udførte en undersøgelse af effektiviteten af at bruge understregninger i programmering af objektnavne. De fandt ud af, at brugen af Camel Case (eller Pascal Case) forbedrede skrivenøjagtigheden og genkendelsen. Understregninger blev meget brugt i C-programmering, men tendensen går i retning af Camel/Pascal Case med nylig vægt på Microsoft- og Java-sprog.
Som med de andre emner, følger en etableret konvention er vigtigere end udvælgelsen af selve konventionen.
En yderligere overvejelse her er databasens store og små bogstaver. SQL Server-sortering bestemmer denne følsomhed med 'CS' (forskel på store og små bogstaver) eller 'CI' (uafhængig af store og små bogstaver) i sorteringsnavnet. For eksempel:
SQL_Latin1_General_Cp437_CS_AS_KI_WI: Case Sensitive SQL_Latin1_General_Cp437_CI_AS_KI_WI: Case Insensitive
I store og små bogstaver Select * from myTable ville fejle mod objektet MyTable . Dette kan gøre understregninger en smule at foretrække for at forhindre forvirring, men Intellisense hjælper også med at eliminere tastefejl i de fleste moderne programmeringsmiljøer.
Andre overvejelser om navngivningskonvention
Singular vs. Plural Debate and the Great Case-spørgsmålet kan være, hvor kampen er den hårdeste, men der er mindst tre områder mere at huske på, når man overvejer en navnekonvention.
Undgå at bruge reserverede SQL Server-ord som objektnavne. Dette omfatter både tabeller og kolonner. For eksempel – Bruger , Tid og Dato er reserveret. Reserverede søgeord kan kræve yderligere omhu at henvise til (såsom brug af firkantede parenteser) afhængigt af den kaldende applikation. Dette gælder også for rum. Mellemrum i objektnavne kræver anførselstegn til reference.
Dette hænger også sammen med en anden anbefaling – præcision. System.CreateDate er langt tydeligere end System.Date . En veldesignet model giver beskueren mulighed for straks at forstå formålet med de underliggende objekter. Når nogen identifikatorer skal refereres som fremmednøgler, skal du være liberal i navnet – Customer.CustomerID i stedet for Customer.ID .
Undgå præfikser og suffikser for tabeller og visninger , såsom tblTable . Ungarsk notation (som altid var beregnet til at identificere variabel brug) gled ind i almindelige SQL Server-navngivningskonventioner, men det er meget hånet. Objektidentifikatorer skal beskrive, hvad der er indeholdt i, ikke selve objektet.
Men præfikser er nyttige i SQL Server-understøttende objekter , da de beskriver objektets funktionelle karakter.
Følgende er almindeligt accepterede præfikser for SQL Server-objekter:
- IX:Indeks
- PK:Primær nøgle
- FK:Fremmednøgle
- CK:Tjek begrænsning
- DF:Standard
- UQ bruges nogle gange også til unikke indekser.
Denne model illustrerer de punkter, der er defineret ovenfor. Det kræver ingen forklaring med hensyn til arten af dataene; ental navngivningskonventioner bruges, og klare identifikatorer er på plads.
I sidste ende er der fordele og ulemper ved hver side af konventionens navnedebatt. Der er dog et nøglepunkt, som begge sider kan blive enige om:Uanset hvilke beslutninger der træffes, skal du være i overensstemmelse med den valgte konvention.
Hvilke SQL-navngivningskonventioner bruger du og hvorfor?