Каково ваше соглашение об именах хранимых процедур?[закрыто]
-
04-07-2019 - |
Вопрос
Я видел различные правила именования хранимых процедур.
Некоторые люди добавляют к имени 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») заставляет меня содрогаться.
Мы используем множество хранимых процедур в разных базах данных со схожей структурой, поэтому для конкретных баз данных мы используем префикс имени самой базы данных;общие процедуры не имеют префикса.Я полагаю, что использование разных схем может быть альтернативой полному избавлению от таких некрасивых префиксов.
Фактическое имя после префикса почти не отличается от имени функции:обычно это глагол типа «Добавить», «Установить», «Создать», «Рассчитать», «Удалить» и т. д., за которым следуют несколько более конкретных существительных, таких как «Пользователь», «Ежедневные доходы» и т. д.
Отвечая на комментарий Анта:
- Разница между таблицей и представлением важна для тех, кто проектирует схему базы данных, а не для тех, кто получает доступ к ее содержимому или изменяет его.В тех редких случаях, когда требуются подробности схемы, их достаточно легко найти.Для обычного запроса SELECT это не имеет значения.На самом деле я считаю, что возможность одинакового обращения с таблицами и представлениями является большим преимуществом.
- В отличие от функций и хранимых процедур, имя таблицы или представления вряд ли будет начинаться с глагола или состоять из одного или нескольких существительных.
- Для вызова функции требуется префикс схемы.Фактически, синтаксис вызова (который мы, во всяком случае, используем) сильно различается у функции и хранимой процедуры.Но даже если бы это было не так, то же самое, что 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