Каково ваше соглашение об именах хранимых процедур?[закрыто]

StackOverflow https://stackoverflow.com/questions/238267

Вопрос

Я видел различные правила именования хранимых процедур.

Некоторые люди добавляют к имени sproc префикс usp_, другие — аббревиатуру имени приложения, а третьи — имя владельца.Вам не следует использовать sp_ в SQL Server, если вы действительно этого не хотите.

Некоторые начинают имя процедуры с глагола (Получить, Добавить, Сохранить, Удалить).Другие подчеркивают имя(я) объекта.

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

Используете ли вы соглашение об именах?Пожалуйста, опишите его и объясните, почему вы предпочитаете его другим вариантам.

Краткое изложение ответов:

  • Кажется, все выступают за единообразие именования, поскольку для всех может быть важнее использовать одно и то же соглашение об именах, чем то, какое конкретное соглашение используется.
  • Префиксы:Хотя многие используют usp_ или что-то подобное (но редко sp_), многие другие используют имя базы данных или приложения.Один умный администратор базы данных использует gen, rpt и tsk, чтобы отличить общие процедуры CRUD от тех, которые используются для отчетов или задач.
  • Слово «Глагол + Существительное» кажется немного более популярным, чем «Существительное + Глагол».Некоторые люди используют ключевые слова SQL (Выбрать, Вставить, Обновить, Удалить) для глаголов, в то время как другие используют глаголы, отличные от SQL (или их сокращения), такие как Получить и Добавить.Некоторые различают существительные в единственном и множественном числе, чтобы указать, извлекается ли одна или несколько записей.
  • В конце, где это уместно, предлагается дополнительная фраза.GetCustomerById, GetCustomerBySaleDate.
  • Некоторые люди используют подчеркивания между сегментами имени, а некоторые избегают подчеркивания.app_ Get_Customer vs.appGetCustomer — думаю, это вопрос читабельности.
  • Большие коллекции процедур можно разделить на пакеты Oracle, решения и проекты Management Studio (SQL Server) или схемы SQL Server.
  • Следует избегать непонятных сокращений.

Почему я выбрал тот ответ, который я сделал: Есть ТАК много хороших ответов.Спасибо вам всем!Как видите, выбрать что-то одно будет очень сложно.Тот, который я выбрал, мне понравился.Я пошел по тому же пути, который он описывает, — пытался использовать глагол + существительное, а затем не смог найти все процедуры, применимые к Клиенту.

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

Поскольку я обычно работаю над очень большими приложениями с сотнями процедур, я предпочитаю самый простой для поиска метод именования.Для небольшого приложения я мог бы предложить вариант «Глагол + существительное», поскольку он соответствует общему соглашению о кодировании имен методов.

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

Это было полезно?

Решение

В моем последнем проекте я использовал usp_[Action][Object][Process], например, usp_AddProduct или usp_GetProductList, usp_GetProductDetail.Однако теперь в базе данных более 700 процедур, становится намного сложнее найти все процедуры для конкретного объекта.Например, теперь мне нужно найти 50 с лишним процедур добавления для добавления продукта и 50 с лишним процедур для получения и т. д.

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

Новый формат выглядит следующим образом

[App]_[Object]_[Action][Process]

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

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

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

Другие советы

Вот некоторые разъяснения по поводу проблемы с префиксом sp_ в SQL Server.

Хранимые процедуры с префиксом sp_ представляют собой системные процедуры, хранящиеся в базе данных Master.

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

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

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

Вот еще один полезный источник, предоставленный Ant в комментарии.

Системы Венгерский (как и приведенный выше префикс «usp») заставляет меня содрогаться.

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

Фактическое имя после префикса почти не отличается от имени функции:обычно это глагол типа «Добавить», «Установить», «Создать», «Рассчитать», «Удалить» и т. д., за которым следуют несколько более конкретных существительных, таких как «Пользователь», «Ежедневные доходы» и т. д.

Отвечая на комментарий Анта:

  1. Разница между таблицей и представлением важна для тех, кто проектирует схему базы данных, а не для тех, кто получает доступ к ее содержимому или изменяет его.В тех редких случаях, когда требуются подробности схемы, их достаточно легко найти.Для обычного запроса SELECT это не имеет значения.На самом деле я считаю, что возможность одинакового обращения с таблицами и представлениями является большим преимуществом.
  2. В отличие от функций и хранимых процедур, имя таблицы или представления вряд ли будет начинаться с глагола или состоять из одного или нескольких существительных.
  3. Для вызова функции требуется префикс схемы.Фактически, синтаксис вызова (который мы, во всяком случае, используем) сильно различается у функции и хранимой процедуры.Но даже если бы это было не так, то же самое, что 1.будет применяться:если я могу одинаково относиться к функциям и хранимым процедурам, почему бы мне этого не сделать?

Начало имени хранимой процедуры с помощьюsp_ это плохо в SQL Server, поскольку все системные процедуры начинаются с sp_.Последовательное именование (даже до степени хобгоблина) полезно, поскольку оно облегчает автоматизированные задачи, основанные на словаре данных.Префиксы в SQL Server 2005 немного менее полезны, поскольку он поддерживает схемы, которые можно использовать для различных типов пространств имен так же, как раньше это делали префиксы в именах.Например, в звездообразной схеме можно было бы иметь тусклый и факт схемы и обращаться к таблицам в соответствии с этим соглашением.

Для хранимых процедур префиксы полезны для идентификации процедур приложения и системных процедур. up_ против. sp_ позволяет относительно легко идентифицировать несистемные хранимые процедуры из словаря данных.

TableName_WhatItDoes

  • Комментарий_GetByID

  • Список_клиентов

  • UserPreference_DeleteByUserID

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

Одно предостережение к вышесказанному:Лично я всегда добавляю ко всем своим автоматически сгенерированным CRUD префикс zCRUD_, чтобы они сортировались до конца списка, где мне не нужно на них смотреть.

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

Префикс :

  • ген - Общие:CRUD, в основном
  • рпт - Отчет:самоочевидный
  • тск - Задача:обычно что-то с процедурной логикой, запускаемое через запланированные задания

Спецификатор действия:

Ins - INSERT
Sel - SELECT
Upd - UPDATE
Del - DELETE

(В тех случаях, когда процедура выполняет множество действий, для выбора спецификатора действия используется общая цель.Например, клиентская команда INSERT может потребовать значительной подготовительной работы, но общая цель — INSERT, поэтому выбран вариант «Ins».

Объект:

Для gen (CRUD) это затрагиваемая таблица или представление.Для rpt (Отчет) это краткое описание отчета.Для tsk (Задача) это краткое описание задачи.

Дополнительные осветлители:

Это необязательные фрагменты информации, используемые для улучшения понимания процедуры.Примеры: «По», «Для» и т. д.

Формат:

[Префикс][Спецификатор действия][Сущность][Необязательные уточнения]

Примеры названий процедур:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

Я всегда инкапсулирую хранимые процедуры в пакеты (Я использую Oracle на работе).Это уменьшит количество отдельных объектов и поможет повторно использовать код.

Соглашение об именах — дело вкуса, и вам следует согласовать его со всеми остальными разработчиками в начале проекта.

для небольших баз данных я использую uspTableNameOperationName, например.uspCustomerCreate, uspCustomerDelete и т. д.Это облегчает группировку по «основному» объекту.

для более крупных баз данных добавьте имя схемы или подсистемы, например.Приемка, покупка и т.д.чтобы они были сгруппированы вместе (поскольку сервер sql любит отображать их в алфавитном порядке)

я стараюсь избегать сокращений в именах для ясности (и новым участникам проекта не придется задаваться вопросом, что означает «UNAICFE», потому что процедура называется uspUsingNoAbbreviationsIncreasesClarityForEveryone)

В настоящее время я использую следующий формат

Обозначение:

[ПРЕФИКС][ПРИЛОЖЕНИЕ][МОДУЛЬ]_[ИМЯ]

Пример:

P_CMS_USER_UserInfoGet

Мне нравится это обозначение по нескольким причинам:

  • начиная с очень простого префикса, можно писать код только для выполнения объектов, начинающихся с префикса (например, для уменьшения SQL-инъекций)
  • в нашей более крупной среде несколько команд работают над разными приложениями, работающими на одной и той же архитектуре базы данных.Обозначение приложения указывает, какая группа владеет SP.
  • Разделы «Модуль» и «Имя» просто завершают иерархию.Все имена должны соответствовать группе/приложению, модулю, функции из иерархии.

Я всегда использую:

usp[Имя таблицы][Действие][Дополнительная информация]

Учитывая таблицу под названием «tblUser», это дает мне:

  • uspUserCreate
  • uspUserSelect
  • uspUserSelectByNetworkID

Процедуры отсортированы в алфавитном порядке по имени таблицы и функциональности, поэтому легко увидеть, что я могу сделать с той или иной таблицей.Использование префикса «usp» позволяет мне узнать, что я вызываю, если я (например) пишу процедуру из 1000 строк, которая взаимодействует с другими процедурами, несколькими таблицами, функциями, представлениями и серверами.

Пока редактор в SQL Server IDE не станет таким же хорошим, как Visual Studio, я сохраняю префиксы.

префикс приложения_ префикс операции_ описание задействованных объектов базы данных (за исключением пробелов между подчеркиваниями — пришлось ставить пробелы, чтобы они отображались).

префиксы операций, которые мы используем -

  • “получать» – возвращает набор записей
  • “входы» — вставляет данные
  • “обновление» — обновляет данные
  • “дель” – удаляет данные

например

wmt_ins_customer_details

«инструмент управления персоналом, вставка деталей в таблицу клиентов»

преимущества

Все хранимые процедуры, относящиеся к одному и тому же приложению, группируются по имени.Внутри группы хранятся хранимые процедуры, выполняющие операции одного и того же типа (например.вставки, обновления и т. д.) сгруппированы вместе.

Эта система хорошо работает для нас, имея ок.1000 хранимых процедур в одной базе данных пришло мне в голову.

Никаких недостатков в этом подходе пока не обнаружил.

GetXXX — получает XXX на основе @ID.

GetAllXXX — получает все XXX.

PutXXX — вставляет XXX, если передан @ID равен -1;еще обновления

DelXXX — удаляет XXX на основе @ID.

Я думаю, что соглашение об именах usp_ никому не принесет никакой пользы.

Раньше я использовал префиксы Get/Update/Insert/Delete для операций CRUD, но теперь, поскольку я использую Linq to SQL или EF для выполнения большей части своей работы CRUD, они полностью исчезли.Поскольку в моих новых приложениях хранится так мало процедур, соглашения об именах больше не имеют значения, как раньше ;-)

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

Если бы у нас не было устаревшего ограничения, я совершенно уверен, что мы бы не использовали префикс.

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

Типичные имена хранимых процедур в нашей команде:

shopGetCategories
shopUpdateItem

Я не думаю, что действительно важно, какой именно у вас префикс, если вы логичны и последовательны.Лично я использую

spu_[описание действия][описание процесса]

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

spu_archiveCollectionData

или

spu_setAwardStatus

Я называю свои функции аналогично, но с префиксом udf_.

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

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

Так что, если вы начнете с чего-то другого, кроме sp_, все станет проще.

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

Кроме того, мы присваиваем префикс, идентифицирующий функцию.Нравиться

Proc_Poll_Interface, Proc_Inv_Interface и т. д.

Это позволяет нам найти все сохраненные процедуры, которые выполняют работу ОПРОСА, а не инвентаризации и т. д.

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

другие, например, функции. 

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Мы следовали именованию на основе функций, поскольку Procs похожи на код/функцию, а не на статические объекты, такие как таблицы.Не помогает то, что Procs может работать более чем с одной таблицей.

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

Надеюсь, это поможет.

Я поздно присоединился к теме, но хочу оставить свой ответ здесь:

В моих последних двух проектах есть разные тенденции, например, в одном мы использовали:

Чтобы получить данные:s<имя таблицы>_G
Чтобы удалить данные:s<имя таблицы>_D
Чтобы вставить данные:s<имя таблицы>_I
Чтобы обновить данные:s<имя таблицы>_U

Этому соглашению об именах также следуют во внешнем интерфейсе, добавляя префикс слова дт.

Пример:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

С помощью приведенных выше соглашений об именах в нашем приложении мы имеем хорошие и легко запоминающиеся имена.

Во втором проекте мы использовали те же соглашения об именах с небольшой разницей:

Чтобы получить данные:sp_<имя таблицы>G
Чтобы удалить данные:sp_<имя таблицы>D
Чтобы вставить данные:sp_<имя таблицы>I
Чтобы обновить данные:sp_<имя таблицы>U

Пример:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU
Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top