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

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

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

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

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

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

Резюме ответов:

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

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

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

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

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

В моем последнем проекте я использовал 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_позволяет относительно легко идентифицировать несистемные хранимые процедуры из словаря данных.

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

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

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

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

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

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

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

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

Пример:

P_CMS_USER_UserInfoGet

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

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

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

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

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

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

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

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

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

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

• « Get » - возвращает набор записей
• « Ins » - вставляет данные
• « Upd » - обновляет данные
• « Del » - удаляет данные

например

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 и т.п.

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

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

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

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

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

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

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

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

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

Для получения данных: s <имя таблицы> _G
Для удаления данных: s <имя таблицы> _D
Для вставки данных: s <имя таблицы> _I
Для обновления данных: s <имя таблицы> _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