Эффективное программирование на T-SQL: Правила именования

Начнем мы с правил именования таблиц, столбцов, переменных, процедур, функций, и других важных объектов базы данных. Ведь это на самом деле очень важно, от удачных имен зависит качество нашего программирования, качество нашего кода и последующее его сопровождение. Хорошие имена - это одно из главных условий понятности нашего кода.

Очень жаль, что об этом мало кто задумывается, особенно программисты, работающие в небольших компаниях, где за кодом следят только они сами или максимум несколько человек.

Следует помнить, что имена, которые мы используем при написании своих инструкций, в первую очередь создаются для программистов, которые будут читать его, в том числе и для нас самих, SQL серверу без разницы, как Вы назвали переменную или таблицу, если ее название не вызывает ошибку.

Если Вы думаете, что Вы пишите хороший и понятный код, прочитайте свои инструкции, которые Вы написали полгода или год назад и больше к ним не возвращались. Сможете ли Вы понять смысл всех переменных, понять с первого взгляда, что содержится в той или иной таблице, в том или ином столбце, что выполняет та или иная функция или процедура?

Я по собственному опыту знаю, что, если не придерживаться определённых правил, с первого взгляда это сделать не получится. Именно поэтому при программировании с использованием языка T-SQL, да и в принципе на любом другом языке программирования, важно выбирать понятные имена, четко и полно отражающие суть того, чем является названная этим именем сущность.

В случае если Вы только начинаете планировать создание приложения, в самом начале работы над проектом необходимо выработать правила именования, сделать некий стандарт, и включить его в документацию. И сделать так, чтобы все, кто работает или будет работать над этим проектом, придерживались этих правил именования.

Какие же преимущества нас ждут, если использовать стандарт именования?

• > Вы сможете сосредоточиться на более важных аспектах кода;

• > Ваш код станет более согласованным;

• > Это позволит легко переключиться на код, который пишут другие программисты, задействованные в проекте, и понимать его. Иными словами, Вам намного легче будет читать как свой собственный код, так и чужой, в любой момент времени;

• > Сокращение периода адаптации нового участника проекта, ведь в этих случаях не нужно осваивать принципы именования, используемые другими сотрудниками, достаточно прочитать стандарт в документации.

В любом случае, наличие хоть какого-то стандарта именования лучше, чем его отсутствие.

Это актуально практически всегда, ответьте на следующие вопросы, если Вы хоть раз ответите «Да», значит, Вам следует разработать такие правила, по крайней мере, для будущих проектов:

• > Над проектом будут работать несколько программистов?

• > Ваш код в дальнейшем будет сопровождаться другими программистами, т.е. они будут вносить в него изменения?

• > В Вашей базе данных реализуется бизнес-логика и бизнес-правила, в ней больше сотни функций и процедур?

• > База данных рассчитана на длительное использование?

На мой взгляд, в большинстве случаев, хоть одно «Да» да будет, поэтому не стоит недооценивать стандарт именования.

Конечно же, стандарт именования у каждого проекта будет с разной степенью формальности. Например, для мелких проектов разрабатывать стандарт со строгой формальностью, т.е. отдельный специальный документ для двух программистов, а то и только для себя, лучше не стоит, так как на это Вы потратите много времени и сил, в этих случаях лучше подойдет неформальный подход, т.е. просто устно определиться с некоторыми моментами, и вести диалог в процессе разработки. Но в случае с крупным проектом, без четко определённого стандарта, зафиксированного на бумаге, как часть проекта, не обойтись, так как это важнейшее средство улучшения читабельности кода и снижение сложности его сопровождения.

Так как же нужно называть таблицы, процедуры, переменные и другие объекты в Microsoft SQL Server? И как не нужно? На эти вопросы я сейчас и попытаюсь ответить.

Общие правила именования для всех объектов базы данных

Перечисленные ниже правила необходимо применять ко всем объектам базы данных Microsoft SQL Server. Уточнения по конкретным объектам будут рассмотрены чуть позже.

Не используйте в названии аббревиатуры

К примеру, если Вы хотите присвоить таблице (или любому другому объекту), которая будет содержать автомобили российского производства, или на английском Russian Made Cars, название RMC, то знать, как расшифровывается эта аббревиатура, будете только Вы, и то недолго. Спустя некоторое время, если Вы не будете постоянно работать с этой таблицей, Вы забудете, почему таблица называется именно RMC и, не заглянув в нее, не поймёте, что она хранит. Про других программистов я вообще молчу, что это за таблица, они смогут понять только тогда, когда спросят об этом Вас, или прочитают в документации, если она у Вас есть.

Мне как-то раз попалось название таблицы ABC, я так и не узнал, для чего она нужна, ведь данные, которые она содержала, были не нормализованы и не отражали никакой сущности. Скорей всего, она вообще создавалась как какое-то временное решение, но впоследствии ее так и не удалили.

В данном конкретном случае идеальное название таблицы Cars, так как оно отражает конкретную сущность, т.е. автомобиль. Имена должны быть максимально конкретны, и своим названием показывать то, чем является эта сущность.

Если Вам нужно отразить в названии дополнительное описание, что это именно автомобили российского производства, то тогда уж лучше так и назвать RussianCars, в любом случае лучше, чем использование аббревиатуры.

Конечно, примерчик, может быть, и так себе, но он показывает суть, что аббревиатуры использовать не стоит.

Это же относится и к функциям, и к процедурам, если в их названии присутствует сокращение в виде аббревиатуры, то узнать, что конкретно делают эти функции и процедуры можно, только если заглянуть в определение этих функций и процедур. В этом случае даже Вы, спустя совсем короткое время, забудете, как именно расшифровывается эта аббревиатура, ведь если с таблицами это можно понять по самим данным, то в случае с функциями и процедурами, если отсутствуют дополнительные комментарии, расшифровать аббревиатуру становиться практически невозможно. Поэтому не используйте аббревиатуры.

В качестве исключения.

Допускается использование общепринятых аббревиатур, которые понятны абсолютно всем, например, таблицу, содержащую справочник ОКВЭД (Общероссийский Классификатор Видов Экономической Деятельности), вполне допустимо назвать OKVED.

Не используйте в именах спецсимволы, пробелы и символы не на латинице

Хоть Microsoft SQL Server и позволяет использовать в именах таблиц, столбцов, представлений, функций или процедур спецсимволы, пробелы и даже русские символы, крайне не рекомендуется это делать. Например, такие объекты можно создать, используя квадратные скобки.

CREATE TABLE [Russian Cars] ( 
   [Name#Авто] VARCHAR(100) NOT NULL 
   ); 
GO 
INSERT INTO [Russian Cars] 
    VALUES ('Название автомобиля'); 
GO 
SELECT [Name#Авто] 
    FROM [Russian Cars];

Рис. 1

Мы видим, что таблица успешно создана, но использовать ее в работе будет очень неудобно, я уже не говорю о том, что будет, если Вы захотите передавать какую-то подобную структуру клиентскому приложению или захотите мигрировать ее в другую СУБД, не факт, что ее вообще стандартными средствами поймут, а в случае с другой СУБД, не факт, что она вообще поддерживает спецсимволы, символы на русском языке и пробелы в именах.

Поэтому никогда не используйте в именах таблиц, столбцов, представлений и других объектов спецсимволы и пробелы, исключения в данном случае не допускаются.

Не используйте ненужные префиксы

Нет никакой необходимости использовать префиксы при названии таблиц, представлений, процедур и некоторых других объектов в БД. Особенно такие префиксы, как tbl_ у таблиц и vw_ у представлений (или t_, pr_ и так далее) - они избыточны. Такие префиксы не несут в себе никакого описания, Вы можете возразить и сказать, что подобные префиксы отражают сущность объекта, т.е. к какому типу объектов он относится, но постойте, извлечь данные в базе данных кроме как из таблиц просто неоткуда, и, если она имеет корректное, правильное название, ее спутать с чем-то просто невозможно. Иными словами, что это таблица, и так понятно, а в случае с представлениями нужно использовать более понятные имена, которые отражали бы то, что возвращает представление. Если, конечно же, Вы присваиваете непонятные имена таблицам и представлениям, то в таких случаях да, Вам это необходимо, но это неправильно.

В случае с другими объектами, широко распространено использование префиксов sp_ для процедур, f_ для функций, trg или trig для триггеров, это также не следует делать. Даже разработчики из Microsoft не рекомендуют использовать префикс sp_, так как он используется для системных процедур в самой СУБД и при определённых обстоятельствах это может вызвать проблемы. В подобных случаях, когда объект выполняет какое-то действие, ему необходимо присвоить понятное имя в формате «глагол-данные», об этом мы поговорим чуть позже.

Исключение.

Есть мнение, в частности Джо Селко говорит, что префиксы в SQL вообще не нужно использовать, но я считаю, что иногда префиксы использовать очень удобно, например, добавив к имени таблицы префикс модуля, к которому она относится. Таким образом, Вы всегда будете знать, где таблица используется и для чего она предназначена.

Например, у меня однажды стояла задача разработать схему в существующей БД, которая содержала бы некие промежуточные данные для их миграции в стороннее приложение. И к таблицам, которые я создавал для работы этого модуля, я добавил определённый префикс, в случае с вышеуказанным примером выглядело бы это, как Mig_Cars. И тем самым у меня ни разу не возникла ситуация, где я бы усомнился в назначении таких таблиц, и какие данные там хранятся. В качестве альтернативы можно, конечно же, было использовать отдельную схему в этой базе данных, но мне нужно было задействовать конкретную схему, поэтому я и решил использовать префикс.

Также есть и другой случай, когда префикс использовать можно: если по каким-либо причинам Вы создаёте временный объект, например, таблицу, которую Вы удалите после выполнения нужной Вам разовой операции.

В подобных случаях называйте таблицу или любой другой объект в БД так, чтобы сразу было понятно, что он не нужен, т.е. подлежит удалению, чтобы программист, который увидит этот объект (например, Вы или кто-то другой забыли удалить этот объект), не воспринимал его как нужный объект в БД. Это как раз и можно сделать с помощью префикса или суффикса, допустим TMP или TEMP, но обязательно используйте одинаковый префикс во всех случаях, т.е. не нужно один раз использовать TMP, а в другой раз как-то по-другому. На начальном этапе разработки сразу договоритесь между всеми участниками проекта, как в таких случаях нужно называть объекты.

В идеале, конечно же, для таких объектов нужно создать отдельную схему, и в ней хранить все ненужное или вовсе не создавать такие объекты, но на практике создание таких объектов все же встречается достаточно часто.

Не заканчивайте и не начинайте имя объекта символом подчеркивания, и не используйте два подряд символа подчёркивания

Не используйте в качестве первого или последнего символа имени объекта базы данных символ подчеркивания. Так создается впечатление, что таблица, представление, функция или процедура какая-то не полноценная, и вводит программиста в заблуждение, он думает, что эту таблицу или процедуру создали временно или для каких-нибудь тестов, в любом случае, он отнесется к ней с недоверием.

Также не нужно ставить два подряд символа подчёркивания, при чтении и написании инструкций два символа подчеркивания можно легко спутать с одним, а если распечатать код на принтере (для документации), то становится вообще непонятно, сколько символов указано, и впоследствии это вызовет серьезные проблемы.

Не используйте в названии цифры

Не нужно использовать в качестве имени таблиц, представлений, функций и других объектов своего рода цифровые суффиксы, например, Orders1, Orders2 или add_order1 и add_order2 и так далее. В таких случаях цифры не вносят в название объекта никакого описательного характера, а только вводят в заблуждение, у программиста, впервые читающего подобный код, сразу возникнет вопрос - в чем отличие Orders1 от Orders2?

Исключение.

Только если цифры действительно вносят ясность в определение сущности, которую представляет собой таблица, или более четко определяют действия процедуры или функции.

Не допускайте орфографических ошибок и опечаток

Если Вы случайно ошиблись в названии объекта, например, вместо названия таблицы Orders Вы написали Opders или Oders. И запустили в работу такое название, впоследствии Вам будет очень сложно его использовать, а другие программисты вообще не поймут, что это за таблица. И даже если Вы потом захотите изменить его, Вам придётся сделать немало дополнительных действий, внести изменения во все инструкции, где участвует эта таблица, поэтому, чтобы этого избежать, лучше сразу проверяйте все имена на предмет их корректности.

Не используйте слишком короткие имена и слишком длинные

Некоторые программисты при создании объектов пытаются или максимально сократить название, объясняя это тем, что впоследствии такое название удобно использовать при написании запросов и инструкций, или наоборот, пытаются в название вложить максимум описательного смысла. И тот, и другой подход неправильный.

Если в первом случае слишком короткие имена просто не несут в себе никакой полезной информации, то во втором - чересчур длинные имена тяжело использовать при написании запросов и инструкций на T-SQL, т.е. такие имена не только придется набирать руками, но их еще и придется просто читать и разбирать, что само по себе вызывает некоторые трудности.

Если применить это к нашему примеру с Russian Made Cars, то первые назвали бы таблицу RusMC или, например, RusMCar, а вторые, например, Tbl_Russian_Made_Cars.

Если во втором случае добавлено лишнее описательное слово Made и описательный префикс Tbl_ (хотя имя по количеству символов не такое уж и Длинное), то в первом случае - вообще кошмар, нарушено не одно правило именования (о некоторых поговорим чуть ниже), и чем является эта таблица, непонятно вообще. Так не нужно делать.

Оптимальная длина именования практически всех объектов в базе данных примерно 8-20 символов. Такого количества обычно достаточно, чтобы присвоить объекту базы данных внятное имя. Можно, конечно, использовать и меньше символов, если выбранное имя в точности описывает конкретную сущность или описывает суть всех выполняемых действий.

Грамотно сокращайте имена

В процессе, когда Вы будете придумывать имена таблицам, представлениям, функциям и процедурам в SQL сервере так, чтобы они максимально отражали конкретную сущность или описывали выполняемые действия, у Вас, в некоторых случаях, будут получаться слишком длинные имена, которые будет неудобно использовать при написании SQL запросов и разработке инструкций на языке T-SQL. И, соответственно, у Вас возникнет и желание, и необходимость сократить такие имена до приемлемого размера, чтобы их было удобно читать и набирать в коде.

Следующие общие правила помогут Вам более грамотно сокращать имена:

• > Исключите из названия различные слова и союзы наподобие and, or, the и так далее;

• > Если название состоит из нескольких слов, каждое слово начинайте с заглавной буквы или разделяйте их нижним подчеркиванием, например, OrderDetails или Order_Details;

• > Следите, чтобы смысл имени в ходе сокращения не изменился, и оно четко отражало сущность, например, OrderDetails хорошее имя, а OrdDetal нет;

У Не сокращайте имена и слова в этом имени только на один символ. Один символ набрать не так уж и сложно, а вот потерять удобочитаемость кода за счет такого сокращения легко;

У Сокращайте имена так, чтобы их можно было удобно и правильно произнести.

Выработайте четкие правила разделения слов в именах

На самом начальном этапе, при разработке правил кодирования, определитесь, каким образом Вы будете отделять слова в именах объектов, и придерживайтесь этого правила везде в этой базе данных. Например, можно для понятного отделения слов использовать способ, который подразумевает каждое новое слово начинать с заглавной буквы OrderDetails, но при этом вполне допустимо использовать способ, в котором слова отделяются нижним подчеркиванием, order_details.

Не нужно писать в одном месте с использованием заглавных букв, а в другом с использованием нижнего подчеркивания, придерживайтесь одного стиля. А какого именно, Вам как раз и нужно определиться на самом начальном этапе разработки.

Таблицы и представления

Таблицы и представления - это те объекты, к которым Вы, наверное, чаще всего будете обращаться, ведь данные из базы данных следует извлекать, а они хранятся в таблицах, имена которых будут использоваться и в представлениях, и в процедурах, и в функциях, тем самым, от того, насколько удачным будет имя таблицы, включая представление, ведь с помощью представления мы также получаем доступ к данным, будет зависеть удобочитаемость всех Ваших инструкций, а также, насколько сложно Вам будет писать все эти инструкции, так как писать код с использованием «неудобных» имен гораздо сложней, чем с использованием понятных и корректных имен.

Здесь я собрал правила, которым следует придерживаться при именовании таблиц и представлений, эти объекты в базе данных в Microsoft SQL Server подчинены примерно одинаковым правилам.

Не используйте единственное число

Таблица сама по себе является множеством, набором данных, поэтому ее никак нельзя называть в единственном числе, например, «Заказ» (Order) или «Автомобиль» (Car). Согласитесь, когда мы говорим «Автомобиль», в голове мы так и представляем один автомобиль, но, если мы говорим «Автомобили», мы уже представляем себе много автомобилей.

Поэтому всегда при названии таблиц или представлений используйте существительные во множественном числе.

В качестве исключения.

Таблица может быть названа в единственном числе, только если в ней действительно будет присутствовать одна строка.

Не используйте похожие имена

Не нужно называть таблицы или представления так, чтобы Вы, или другой программист, могли их спутать. К примеру, если Вам нужно назвать таблицу, которая будет содержать более детализированные данные заказов, а при этом таблица с названием OrderDetails уже есть, не нужно создавать таблицу с названием Order_Details, лучше добавьте дополнительное описательное слово, которое будет характеризовать конкретную детализацию, например, OrderDetailsMoney, по названию которой можно легко понять, что таблица содержит какие-то детализированные сведения о заказах в части денежных средств.

Временные таблицы подчиняются тем же правилам, что и обычные таблицы

Временные таблицы стоит называть с учетом тех же правил, что и обычные таблицы, ведь это такой же набор данных. Иными словами, у нее также должно быть хорошее имя во множественном числе, по которому сразу понятно, что содержит эта таблица.

Не нужно в названии временной таблицы использовать префикс, допустим, tmp или temp или любой другой, по символу #, который используется для создания временных таблиц, и так сразу понятно, что это таблица временная.

Столбцы в таблицах и переменные

При именовании столбцов в таблицах, т.е. элементов данных, и переменных, также следует придерживаться нескольких правил, чтобы Вам и другим программистам, которые будут работать с базой данных, было удобно писать SQL запросы и извлекать данные.

Для имени столбца используйте единственное число

Если таблица - это множество, то строка в таблице - это что-то конкретное, поэтому нужно называть её в единственном числе.

Достаточно часто встречается, что в названии столбца дублируется название таблицы, например, orders_id, в таких случаях в процессе написания SQL запросов Вы можете столкнуться с проблемами дублирования, что-то вроде Orders.orders_id, и если такого кода будет много, то это значительно усложнит его читабельность.

Называть столбцы, например, просто id также не следует, это слишком общее имя, оно мало дает информации об этом элементе данных. Тем более в документации, если у Вас такая будет вестись, будет столько id, что понять, какое из этих id чем является, будет достаточно сложно. В случае с таблицей Orders, оптимальным вариантом будет назвать столбец с идентификатором OrderId или order_id, т.е. в единственном числе.

Не присваивайте слишком общие имена характеристикам

Если столбец или переменная имеет настолько общее имя, которое ничего не говорит о том, чем является этот элемент данных, - это плохо. Например, столбец Dt или Data, это дата чего? Заказа? Оформления заказа? Оплаты заказа? Создания заказа? Может быть, это дата рождения?

Даже если по названию таблицы или по окружающему коду можно определить назначение того или иного столбца или переменной, например, в таблице используется только один столбец с датой, это еще не говорит о том, что в будущем Вы не будете добавлять дополнительные столбцы в таблицу или расширять код процедуры, поэтому лучше сразу называйте и столбцы, и переменные более конкретно, например, название OrderDate или order_date, четко говорит нам о том, что это дата заказа.

В случае с переменными также не стоит присваивать имена переменным, которые будут содержать некий признак, флаг или статус, имена наподобие: priz, flag, или status, лучше придумайте имя, которое будет четко отражать суть данных и иметь смысл.

Например, у Вас есть некий признак или тип заказа, по которому Вы отбираете заказы, не нужно называть переменную в этом случае просто type или priz. Если встретить такие переменные в середине кода, возникнет вопрос, что это за тип или признак чего? Если процедура большая, и даже если она связана только с заказами, не факт, что type или priz, это тип или признак заказа. Лучше назовите переменную @TypeOrder, тогда то, что это тип заказа, будет понятно сразу.

Называйте одну и ту же характеристику во всех таблицах одинаково

Не стоит в одной таблице называть столбец OrderDate, а в другой, где используется подобная характеристика, DateOrder или как-то по-другому. У человека, который будет читать данный код, это вызовет замешательство, даже для Вас самих это будет просто неудобно, когда Вы начнете объединять эти таблицы в запросах.

Также не стоит называть переменную в одной процедуре или функции одним именем, а переменную, которая будет содержать точно такие же данные, но в другой процедуре, другим именем. Допустим, Вы назвали переменную в одной процедуре @ProductName, а в другой просто @Product или @Name . В таком случае быстро переключиться с одного кода на другой не получится, а если эти процедуры взаимосвязаны и редактируются одновременно, то запутаться очень легко.

Поэтому необходимо придерживаться одного стиля именования, так Вам легче будет читать и понимать код во всех процедурах, и, соответственно, сопровождать этот код. К тому же Вам уже не нужно будет думать над именем новой переменной, если Вы знаете, какие именно данные она будет хранить. Например, если Вам нужно создать переменную, которая будет хранить наименование товара, при этом Вы знаете, что в базе данных этот элемент данных называется ProductName, у Вас даже в мыслях не возникнет идеи назвать данную характеристику по-другому.

Не используйте похожие имена

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

Например, если Вы уже присвоили имя столбцу, допустим, ProductName, не нужно создавать столбец в этой же таблице с именем скажем ProductNam, NameProduct или ProductNeme, придумайте более описательное имя.

В случае с переменными можно встретить имена, которые различаются только на цифровую приставку, например, @ProductName1, @ProductName2 и так далее. Чтобы понять, для чего нужны такие переменные, необходимо разобрать весь код. Все это ведет только к запутыванию и усложнению кода.

Не используйте символ подчеркивания в начале и в конце имени

Использовать символ подчеркивания, в начале или в конце названия столбца или переменной не нужно, во-первых - зачем? Никакого смысла данный символ не придаст имени столбца или переменной. А во-вторых - это также будет вводить в заблуждение программистов, читающих код.

Лично у меня, если бы я встретил в таблице столбец с именем _ProductName, сложилось бы впечатление, что такой столбец вообще не нужен, и возник бы вопрос, для чего он тогда вообще здесь?

В случае со столбцами и переменными использовать два символа подчеркивания подряд также не стоит по тем же причинам, что и в именах объектов базы данных, т.е. при чтении кода два символа подчеркивания можно легко спутать с одним.

Не используйте в именах переменных название типов данных

Придумывайте переменным имена, отражающие суть данных, которые они хранят. Включать в имена название типа данных или его часть не стоит. Ведь имена наподобие @Text или @BigVarchar описывают компьютерные данные, а не конкретную задачу, т.е. данные, для которых эта переменная и создалась. Если встретить в коде переменную с таким названием, будет понятно, что она содержит какие-то большие текстовые данные, но какие?

Не называйте переменные коротким именем

Самый важный принцип именования переменных состоит в том, что имя должно полно и в точности описывать сущность данных, которую хранит переменная. А такие названия, как @Var, @Per, @tmp или просто @x, или еще хуже - с добавленными к ним цифрами, не несут в себе никакого описательного смысла. Программист, который в коде встретит такую переменную, даже если это Вы сами, должен будет проанализировать окружающий код этой переменной, для того чтобы понять, для чего она нужна. Поэтому сразу присваиваете описательные имена переменным, например, по имени @PeriodId, сразу понятно, что это идентификатор периода (в данном случае имен @Per или @p следует избегать).

Даже в случае с циклами переменные, которые используются для счетчика, лучше называть описательным именем, а не как мы все любим @i, @row или @num. Особенно это касается вложенных циклов. В данном случае запутаться очень легко, а вот понять в чем ошибка, если стоит цель найти ошибку в коде, достаточно трудно. Также, если переменную счетчика предполагается использовать вне цикла, лучше дать ей более выразительное имя.

Например, после завершения цикла или любой другой обработки, Вам необходимо вернуть количество обработанных или задействованных записей, вместо того, чтобы использовать переменную @cnt для возвращения информации о количестве заказов, назовите переменную @CountOrders, такое имя в точности отражает суть данных.

Не называйте переменные именем, отражающим значение

Даже если переменная по своей сути является константой, например - 5, не нужно переменную называть @Five. Если по каким-либо причинам Вам потребуется изменить значение переменной, скажем на 6, согласитесь, что переменная @Five со значением 6 будет смотреться как минимум странно и неинформативно. Для исправления ситуации Вам потребуется изменять название переменной во всех местах, где она используется.

В подобных случаях назовите переменную тем именем, чем по сути является число 5.

Процедуры, функции и триггеры

В Microsoft SQL Server такие объекты, как процедуры, функции и триггеры, выполняют некий алгоритм действий, название каждого конкретного объекта должно четко характеризовать этот алгоритм, чтобы программист, взглянув на название процедуры или функции, сразу понял, для чего она предназначена. Программист не должен заглядывать в определение функции или процедуры с целью узнать, что же она там делает, как я ее могу использовать.

Имя процедуры или функции должно описывать задачу или проблему, но не ее решение

Не нужно называть процедуру по тем действиям, которые она непосредственно и делает, например, в случае с добавлением нового сотрудника не нужно называть процедуру New_Row_Employees.

Лучше в названии описать саму задачу, например, в этом случае процедуру лучше назвать Add_New_Employee, т.е. сразу понятно, что это процедура добавляет нового сотрудника, а не просто создает новую строку в таблице Employees.

Применяйте правило «глагол-данные» при именовании процедур

При именовании процедур и триггеров следует применять правило «глагол-данные», т.е. в названии Вы пишете сначала, что делает этот объект, а затем - над чем.

Вот небольшой пример:

Процедура добавления нового сотрудника может называться (Добавить нового сотрудника)

Add_NewEmployee или Add_New_Employee

Процедура изменения характеристик сотрудника (Редактировать сотрудника)

Edit_Employee

Процедура удаления сотрудника (Удалить сотрудника)

Remove_Employee

Скалярные функции называйте в единственном числе

В случае с функциями правило «глагол-данные» работать не будет, ведь все функции что-то выводят и что-то получают, так у Вас все функции могут быть с префиксом, например, Get. Лучше используйте название, которое будет четко характеризовать итоговый результат, а также, при именовании скалярных функций, используйте единственное число, ведь такая функция возвращает что-то конкретное, например:

Функция получения стоимости заказа

OrderPrice()

Функция получения номера заказа

OrderNumber()

По названию видно, что эти функции возвращают что-то конкретное, ничего лишнего в данном случае писать не требуется.

Табличные функции называйте во множественном числе

Здесь действуют практически те же самые принципы именования, что и в случае с таблицами. Так табличные функции следует называть во множественном числе, ведь они возвращают набор данных.

Например, табличную функцию, которая будет возвращать информацию о повторных заказах, можно назвать

RepeatOrders()

Ограничения и индексы

Это единственные объекты в БД, где можно и даже рекомендовано использовать префиксы или суффиксы. Но, снова повторюсь, Вы должны выработать определённые правила с самого начала разработки, зафиксировать их, и придерживаться этих правил должны все и всегда.

В случае с ограничениями Вы можете придерживаться общепризнанных префиксов, которые используем в SQL Server:

PK_ - ограничение первичного ключа;

FK_ - ограничение внешнего ключа;

CK_ - проверочное ограничение;

UQ_ - ограничение, обеспечивающее уникальность значений;

DF_ - значение по умолчанию.

При этом само имя в любом случае должно четко отражать суть этого ограничения, так например, по имени ограничения DF_First_Column непонятно, что это за ограничение, а вот DF_Category уже более понятно имя, т.е. это значение по умолчанию для столбца Category. Иногда можно встретить и такое, что к этому имени ограничения могут добавлять еще и имя таблицы, например, DF_Goods_Category, но данный принцип лучше использовать для ограничения внешнего ключа, показывая тем самым название внешней таблицы, в случае со значением по умолчанию - это избыточно.

Кроме того, имя ограничения отображается в сообщении об ошибке, когда это ограничение нарушено. Поэтому понятное имя ограничения даст Вам нужную информацию для того, чтобы быстро диагностировать ошибку.

В индексах можно использовать префикс IX_ или суффикс _idx, это также общепринятые обозначения этого типа объектов в Microsoft SQL Server.

Почему же здесь можно использовать префиксы и суффиксы? Дело в том, что в случае с ограничениями это просто выглядит более наглядно и понятно, чем без этого дополнительного префикса. Например, даже в Management Studio, если смотреть на ключи и ограничения, визуально мы гораздо быстрей поймём о назначении того или иного ограничения, если в имени будет описательный префикс. А индексы вообще не имеют отношения к модели данных, префиксом мы просто показываем, что этот объект является индексом.