Ve světě databází jsou některé věci, na kterých se všeobecně souhlasí. Zvýšená RAM je do značné míry prospěšná pro systémy DMBS. Rozložení dat a souborů protokolu na RAID zvyšuje výkon.
Konvence pojmenování nejsou jednou z těchto věcí.
Jde o překvapivě polarizující téma, zastánci různých metodologií jsou pevně zakotveni ve svých pozicích. A velmi hlasitě a vášnivě obhajují totéž.
Tento článek se ponoří do některých konkrétních konvencí a argumentů na obou stranách a zároveň se pokusí předložit rozumný závěr pro každý bod.
Velká debata o pluralizaci
V jádru je to jednoduché téma. Jaký je například správný způsob pojmenování tabulky obsahující informace o zákaznících ve schématu relační databáze? Je to Customer? nebo Customers ?
Argumenty na obou stranách jsou plné.
Na první pohled , je přirozené uvažovat o sbírce objektů v množném čísle. Skupina několika jednotlivců nebo společností by byla zákazníky . Proto by tabulka (což je kolekce objektů) měla být pojmenována v množném čísle. Jednotlivý řádek v této tabulce by byl jeden zákazník .
Principy pojmenování ISO/IEC, i když jsou zastaralé, doporučují názvy tabulek v množném čísle a názvy sloupců v jednotném čísle.
Většina systémových tabulek SQL Server používá názvy v množném čísle (sysnotifications , systémoví operátoři ), ale to je nekonzistentní. Proč sysproxylogin a nikoli sysproxyloginy ?
V argumentech pro názvy tabulek v množném čísle jsou řádky v tabulce také označovány jako „instance“ celku – podobně jako položky v kolekci. Zákazníci definuje celý soubor; jediný zákazník je instancí Customers .
A naopak, existuje mnoho důvodů, proč používat singulární názvy objektů.
I když může existovat mnoho položek (nebo zákazníků ) v tabulce lze samotnou tabulku považovat za jednu entitu. krabice zákazníků není „krabička zákazníků“, i když má uvnitř velký počet zákazníků. Navíc v tabulce může být pouze jedna položka – nebo žádná –, což z „zákazníků“ dělá nesprávné označení.
Pokud se rozhodnete změnit název tabulky na základě variant slov, mohou se rychle objevit nekonzistence. I když mnoho slov bude jednoduchých (Zákazník se stává Zákazníky , Produkt se stává Produkty ), jiná slova nemusí být. V tomto případě Osoba mohli stát Lidé nebo Osoby; jednotného čísla los by vypadalo stejně jako jeho množné číslo, Moose . (I když proč byste potřebovali stůl s losy?) Konvence jako People.FirstName začíná být matoucí nejasné.
Pokud se jedná o více jazyků, situace se ještě zhorší. Vzhledem k tomu, že pluralita slov se může v mnoha ohledech lišit (zákazníci, myši, los, děti, krize, osnovy, letadla), mají nerodilí mluvčí další výzvy. Držení se singulárních názvů objektů tomuto problému zcela zabrání.
Otázka případové úmluvy
S konvencemi velkých a malých písmen není stejná horlivost jako s pluralizací, ale argumentuje se pro několik různých možností. Patří mezi ně:
- Případ Pascal :První písmeno každého zřetězeného slova je velké, jako v:
CustomerOrder -
Camel Case :První písmeno prvního slova je malé; všechna následující zřetězená slova mají první písmeno velké, jako v:
customerOrderPascal Case je někdy považován za podtyp Camel Case, ale Microsoft mezi nimi obecně rozlišuje.
U slov kratších než tři znaky se doporučuje používat pouze velká písmena, jako v
UIneboIO. - Podtržítko [případ „C“] :Slova jsou oddělena podtržítky, jako v
Customer_Ordernebocustomer_Order– ještě více rozhodnutí!
Výzkumníci z Johns Hopkins University provedli studii o účinnosti používání podtržítek při programování názvů objektů. Zjistili, že použití Camel Case (nebo Pascal Case) zlepšilo přesnost psaní a rozpoznávání. Podtržítka byla široce používána v programování v C, ale trend směřuje k Camel/Pascal Case s nedávným důrazem na Microsoft a jazyky ve stylu Java.
Stejně jako u ostatních témat následujících zavedená konvence je důležitější než výběr samotné úmluvy.
Dalším aspektem je zde rozlišování velkých a malých písmen v databázi. Porovnání SQL Server určuje tuto citlivost pomocí ‚CS‘ (rozlišují se malá a velká písmena) nebo ‚CI‘ (nerozlišují se malá a velká písmena) v názvu porovnávání. Například:
SQL_Latin1_General_Cp437_CS_AS_KI_WI: Case Sensitive SQL_Latin1_General_Cp437_CI_AS_KI_WI: Case Insensitive
U řazení rozlišujících velká a malá písmena Select * from myTable selže proti objektu MyTable . Díky tomu může být podtržítka o něco vhodnější, aby se předešlo zmatkům, ale Intellisense také pomáhá eliminovat překlepy ve většině moderních programovacích prostředí.
Další aspekty konvence pojmenování
Debata o jednotném čísle vs. množné číslo a otázka Velkého případu mohou být místem, kde je bitva nejzuřivější, ale při zvažování konvence pojmenování je třeba mít na paměti nejméně tři další oblasti.
Nepoužívejte jako názvy objektů žádná vyhrazená slova SQL Server. To zahrnuje jak tabulky, tak sloupce. Například – Uživatel , Čas a Datum jsou rezervovány. Vyhrazená klíčová slova mohou vyžadovat další péči o odkazování (například použití hranatých závorek) v závislosti na volající aplikaci. To platí i pro prostory. Mezery v názvech objektů vyžadují k odkazování uvozovky.
S tím souvisí i další doporučení – přesnost. System.CreateDate je mnohem jasnější než System.Date . Dobře navržený model umožňuje divákovi okamžitě porozumět účelu podkladových objektů. Pokud mají být jakékoli identifikátory odkazovány jako cizí klíče, buďte v názvu liberální – Customer.CustomerID spíše než Customer.ID .
U tabulek a zobrazení se vyhněte předponám a příponám , například tblTable . Maďarská notace (která byla vždy určena k identifikaci použití proměnné) vklouzla do běžných konvencí pojmenování SQL Serveru, ale je široce zesměšňována. Identifikátory objektu by měly popisovat to, co je v něm obsaženo, nikoli objekt samotný.
Nicméně předpony jsou užitečné v objektech podporujících SQL Server , protože popisují funkční povahu objektu.
Následují běžně přijímané předpony pro objekty SQL Server:
- IX:Index
- PK:Primární klíč
- FK:Cizí klíč
- CK:Kontrola omezení
- DF:Výchozí
- UQ se někdy používá také pro jedinečné indexy.
Tento model ilustruje body definované výše. Nevyžaduje žádné vysvětlení, pokud jde o povahu údajů; používají se jednotné konvence pojmenování a jsou zavedeny jasné identifikátory.
Koneckonců, každá strana debaty o pojmenování podle konvence má své výhody a nevýhody. Existuje však jeden klíčový bod, na kterém se mohou obě strany shodnout:bez ohledu na přijatá rozhodnutí buďte konzistentní s vybranou konvencí.
Jaké konvence pojmenování SQL používáte a proč?