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

В моем последнем проекте я использовал 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_, являются системными sprocs, хранящимися в базе данных Master.

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

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

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

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

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

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

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

В ответ на комментарий Ant:

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

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

Префикс:

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

Указатель действия:

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

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

Объект:

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

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

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

Формат:

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

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

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

TableName_WhatItDoes

• Comment_GetByID

• Customer_List

• UserPreference_DeleteByUserID

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

P_CMS_USER_UserInfoGet

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

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

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

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

Учитывая таблицу с именем "tblUser", я получаю:

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

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

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

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

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

• «get» - возвращает набор записей
• «ins» - вставляет данные.
• «upd» - обновляет данные
• «del» - удаляет данные

e.g

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 

or

spu_setAwardStatus

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

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

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

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

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

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

Proc_Poll_Interface, Proc_Inv_Interface и т. Д.

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

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

другие функции eg.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

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

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

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

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

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

Для получения данных: s ‹tablename› _G
Для удаления данных: s ‹tablename› _D
Для вставки данных: s ‹tablename› _I
Для обновления данных: s ‹tablename› _U

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

Пример:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

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

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

Для получения данных: sp_ ‹tablename› G
Для удаления данных: sp_ ‹tablename› D
Для вставки данных: sp_ ‹tablename› I
Для обновления данных: sp_ ‹tablename› U

Пример:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU