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

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

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

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

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

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

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

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

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

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

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

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

shopGetCategories
shopUpdateItem

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

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

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

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

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

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

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

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

spu_archiveCollectionData 

или же

spu_setAwardStatus

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

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

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

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

В моем последнем проекте я использовал 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.

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

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

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

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

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

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

Избегайте 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 могут работать более чем с одной таблицей.

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

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

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

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

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

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

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

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

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

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

• «получить» - возвращает набор записей
• «ins» - вставляет данные
• «UPD» - обновляет данные
• «дель» - удаляет данные

например

wmt_ ins _ customer _details

"инструмент управления персоналом, вставьте детали в таблицу клиентов"

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

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

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

Минусов у такого подхода пока не обнаружено.

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

Префикс:

• 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

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

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

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

Пример:

P_CMS_USER_UserInfoGet

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

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

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

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

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

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

TableName_WhatItDoes

• Comment_GetByID

• Customer_List

• UserPreference_DeleteByUserID

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

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

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

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

To get Data : s<tablename>_G
To delete Data : s<tablename>_D
To insert Data : s<tablename>_I
To update Data : s<tablename>_U

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

Пример:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

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

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

To get Data : sp_<tablename>G
To delete Data : sp_<tablename>D
To insert Data : sp_<tablename>I
To update Data : sp_<tablename>U

Пример:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU