Неемоционален логически поглед към конвенциите за именуване на SQL Server

В света на базата данни има някои неща, които са общоприети. Увеличената RAM е до голяма степен от полза за DMBS системите. Разпространението на данни и регистрационни файлове в RAID подобрява производителността.

Конвенциите за именуване не са едно от тези неща.

Това е изненадващо поляризираща тема, като привържениците на различни методологии са здраво закрепени в своите позиции. И много гласови и страстни в защитата на същото.

Тази статия ще се задълбочи в някои от специфичните конвенции и аргументите от двете страни, като същевременно ще се опита да представи разумно заключение за всяка точка.

Големият дебат за плурализиране

В основата си това е проста тема. Например, какъв е правилният начин за именуване на таблица, която съдържа информация за клиента в схема на релационна база данни? Това ли е Customer или Customers ?

Аргументите и от двете страни изобилстват.

На пръв поглед , естествено е да мислим за колекция от обекти в множествено число. Група от няколко лица или компании ще бъдат Клиенти . Следователно, таблица (която е колекция от обекти) трябва да бъде именувана в множествено число. Отделен ред в тази таблица ще бъде един клиент .

ISO/IEC принципите за именуване, макар и датирани, препоръчват имена на таблици в множествено число и имена на колони в единствено число.

Повечето системни таблици на SQL Server използват имена в множествено число (sysnotifications ,сисоператори ), но това е непоследователно. Защо sysproxylogin а неsysproxylogins ?

В аргументите за имена на таблици за множествено число, редовете в таблицата също се споменават като „екземпляри“ на цяло – подобно на елементите в колекция. Клиенти дефинира цялото множество; един клиент е екземпляр на Клиенти .

Обратно, има много причини да се използват единствени имена на обекти.

Въпреки че може да има много артикули (или клиенти ) в таблица самата таблица може да се счита за едно цяло. кутия с клиенти не е „кутия с клиенти“, дори ако има голям брой клиенти вътре. Освен това може да има само един елемент – или никакъв – вътре в таблицата, което прави „клиентите“ погрешно наименование.

Ако изберете да промените името на таблицата въз основа на варианти на думи, бързо могат да се появят несъответствия. Докато много думи ще бъдат ясни (Клиент става Клиенти , Продукт става Продукти ), други думи може да не са. В този случай Лице може да стане Хора или Лица; единствено число лос ще изглежда по същия начин като формата му за множествено число, Moose . (Въпреки че защо ще имате нужда от маса с лосове?) Конвенция като People.FirstName започва да става объркващо неясно.

Ако са включени няколко езика, ситуацията се влошава още повече. Тъй като множественото число на думите може да варира по толкова много начини (клиенти, мишки, лосове, деца, кризи, учебни програми, самолети), говорещите, които не са роден език, имат допълнителни предизвикателства. Придържането към единични имена на обекти избягва напълно този проблем.

Въпрос на конвенцията на случая

Няма същия плам с конвенциите за случаи, както при множественото число, но се аргументират за няколко различни варианта. Те включват:

• Случай на Pascal :Първата буква на всяка свързана дума е главна, както е в:CustomerOrder

• Калъф за камила :Първата буква на първата дума е малка; всички следващи свързани думи имат главна първа буква, както е в:customerOrder

  Pascal Case понякога се счита за подтип на Camel Case, но Microsoft обикновено прави разлика между двете.

  За думи по-малко от три знака се препоръчва да използвате само главни букви, както е в UI или IO .

• Подчертаване [„C“ Case] :Думите са разделени с долни черти, както в Customer_Order или customer_Order – още повече решения!

Изследователи от университета Джон Хопкинс проведоха проучване за ефективността на използването на долни черти при програмиране на имена на обекти. Те открили, че използването на Camel Case (или Pascal Case) подобрява точността на писане и разпознаването. Подчертанията бяха широко използвани в програмирането на C, но тенденцията е към Camel/Pascal Case с неотдавнашен акцент върху езиците в стил Microsoft и Java.

Както и при другите теми, следва установената конвенция е по-важна от селекция на самата конвенция.

Допълнително съображение тук е чувствителността на малки и малки букви на базата данни. Съпоставянето на SQL Server определя тази чувствителност с „CS“ (чувствителен към главни и малки букви) или „CI“ (независим от главни букви) в името на съпоставянето. Например:

SQL_Latin1_General_Cp437_CS_AS_KI_WI: Case Sensitive
SQL_Latin1_General_Cp437_CI_AS_KI_WI: Case Insensitive

При съпоставяния, чувствителни към главни букви, Select * from myTable би се провалил спрямо обекта MyTable . Това може да направи долните черти малко за предпочитане, за да се предотврати объркване, но Intellisense също помага за премахване на грешки при въвеждане в повечето съвременни среди за програмиране.

Други съображения за конвенцията за именуване

Дебатът за единствено число срещу множествено число и въпросът за големия случай може да са мястото, където битката е най-ожесточена, но има поне още три области, които трябва да имате предвид, когато обмисляте конвенция за именуване.

Избягвайте да използвате каквито и да е запазени думи на SQL Server като имена на обекти. Това включва както таблици, така и колони. Например – Потребител , Време и Дата са запазени. Запазените ключови думи може да изискват допълнителни грижи за препращане (като използване на квадратни скоби) в зависимост от извикващото приложение. Това важи и за пространствата. Интервалите в имената на обекти изискват кавички за препратка.

Това също е свързано с друга препоръка – прецизност. System.CreateDate е далеч по-ясно от System.Date . Добре проектираният модел позволява на зрителя веднага да разбере предназначението на основните обекти. Когато някакви идентификатори трябва да бъдат посочени като външни ключове, бъдете свободни в името – Customer.CustomerID вместо Customer.ID .

Избягвайте префикси и суфикси за таблици и изгледи , като например tblTable . Унгарската нотация (която винаги е била предназначена да идентифицира използването на променлива) се вмъкна в общите конвенции за именуване на SQL Server, но е широко осмивана. Идентификаторите на обекта трябва да описват това, което се съдържа вътре, а не самия обект.

Въпреки това, префиксите са полезни в обекти, поддържащи SQL Server , тъй като те описват функционалната природа на обекта.

Следните са общоприети префикси за обекти на SQL Server:

• IX:Индекс
• PK:Първичен ключ
• FK:Външен ключ
• CK:Проверка на ограничението
• DF:По подразбиране
• UQ понякога се използва и за уникални индекси.

Този модел илюстрира точките, определени по-горе. Не изисква обяснение относно естеството на данните; използвани са единични конвенции за именуване и са налице ясни идентификатори.

В крайна сметка има предимства и недостатъци за всяка страна от дебата за наименуването на конвенцията. Има обаче един ключов момент, по който и двете страни могат да се споразумеят:независимо от взетите решения, бъдете последователни с избраната конвенция.

Какви SQL конвенции за именуване използвате и защо?