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

Ответ 1

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

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

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

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

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

Это помогает группировать вещи для более легкого поиска позже, особенно если есть большое количество sprocs.

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

Ответ 5

TableName_WhatItDoes

• Comment_GetByID

• Customer_List

• UserPreference_DeleteByUserID

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

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

Ответ 6

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

Префикс:

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

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

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

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

Объект:

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

Дополнительные расширители:

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

Формат:

[Префикс] [Action Specifier] [Entity] [Дополнительные расширители]

Примеры имен процедур:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

Ответ 7

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

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

Ответ 8

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

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

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

Ответ 9

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

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

[PREFIX] [ПРИМЕНЕНИЕ] [МОДУЛЬ] _ [ИМЯ]

Пример:

P_CMS_USER_UserInfoGet

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

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

Ответ 10

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

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

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

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

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

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

Ответ 11

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

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

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

например

wmt_ ins _ customer _details

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

<сильные > преимущества

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

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

Пока не сталкивались с какими-либо недостатками этого подхода.

Ответ 12

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

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

PutXXX - Вставляет XXX, если он принят @ID равен -1; Другие обновления

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

Ответ 13

Я думаю, что соглашение об именах usp_ ничего не делает.

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

Ответ 14

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

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

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

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

shopGetCategories
shopUpdateItem

Ответ 15

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

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

где описание действия является одним из небольшого диапазона типичных действий, таких как get, set, archive, insert, delete и т.д. Описание процесса является чем-то коротким, но описательным, например

spu_archiveCollectionData 

или

spu_setAwardStatus

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

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

Ответ 16

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

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

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

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

Proc_Poll_Interface, Proc_Inv_Interface и т.д.

Это позволяет нам находить все сохраненные procs, которые выполняют работу POLL vs, которая делает Inventory и т.д.

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

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

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

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

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

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

Ответ 17

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

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

Получить данные: 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

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

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

Получить данные: sp_ <tablename> G
Для удаления данных: sp_ <tablename> D
Чтобы вставить данные: sp_ <tablename> я
Чтобы обновить данные: sp_ <tablename> U

Пример:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU