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


122

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

Некоторые люди добавляют к имени 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.


1
Что означает usp?
Midhat

2
Я считаю, что usp - это сокращение от «пользовательская процедура». Это отличает его от системных процедур с префиксом sp_. Это важное различие, о чем вы можете прочитать в ответах.
DOK

спасибо док. grazie mille
Midhat


1
Я поддерживаю его только потому, что он закрыт, надеюсь, чтобы показать сильным мира сего, что подобные вопросы полезны для сообщества.
tsilb

Ответы:


66

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


3
Что делать, если задействовано более одного объекта? Например, что, если sproc запрашивает информацию как из таблицы Customer, так и из таблицы Orders?
DOK

2
Спасибо, Митч, давайте проясним. Этот префикс «Приложение» является заполнителем для другой аббревиатуры, указывающей фактическое имя приложения (или аббревиатуру). Таким образом, если 3 приложения используют одну базу данных, могут быть ICA_Product_Add, CRM_Product_Add и BPS_Product_Add.
DOK

2
Зачем дублировать каждую процедуру 3 раза для 3 приложений? Весь смысл процедур хранения в том, чтобы иметь единое место, где происходит данное действие. «ICA_Product_Add, CRM_Product_Add и BPS_Product_Add» уничтожает это.
Джейсон Кестер,

3
Джейсон, эти sprocs могут быть вставлены в разные таблицы. У них могут быть разные входные параметры или возвращаемые значения. Или у них может быть другое поведение. Если sprocs делают то же самое, я согласен, версия должна быть только одна. Как предположил кто-то другой, общие sprocs могут не иметь префикса.
DOK

1
Если у вас есть несколько приложений, вызывающих одну и ту же процедуру, вам нужно быть особенно осторожным, любое изменение этой процедуры может нарушить работу этих нескольких приложений. Что касается наименования, это серая область, но вы можете назвать ее общим / глобальным или как угодно. @localghosts: спасибо за информативность.
dnolan

36

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

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

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

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

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

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


Хм, я не понимаю. Почему sp снижает производительность? Usp или gsp в порядке?
Эрвин Ройаккерс

1
@ user2609980 DOK говорит, что SQL Server sp_сначала ищет префиксную процедуру в главной БД, а затем в текущей БД, если не найден
GôTô

+1 за четкое указание чего-то, что имеет более запутанные объяснения в другом месте. Для меня это не новость, но я думаю, что это простое и краткое объяснение для начинающих.
undrline

Ссылка на демонстрацию хита производительности взята из статьи, написанной в 2001 году. С тех пор она изменилась, вот более подробная статья (от 2012 года) Аарона Бертрана: sqlperformance.com/2012/10/t-sql-queries/sp_prefix
Майкл Дж. Сварт,

16

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

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

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

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

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

1
Так вот, как узнать, взаимодействуете ли вы с процедурой, функцией, представлением, таблицей или чем-то еще?
Ant

1
Я бы предположил, что функции могут начинаться с «Get» или быть именем, которое не начинается с глагола. Все остальное будет процедурой, потому что в конце концов они называются хранимыми процедурами. Процедуры скрывают такие особенности, как представления, таблицы и все остальное.
Mark Stock

3
Но это не венгерский. «Usp» - это не объявление переменной венгерского языка. «U» не означает «обновление», это означает «пользователь», как в «определяемой пользователем хранимой процедуре», и это просто защищает от SQL Server, просматривающего главную базу данных каждый раз, когда он ищет вашу хранимую процедуру. Естественно, есть и другие способы, но «usp» обычно считается стандартом во многих корпусах, и, судя по тому, что я видел, он работает хорошо. Этому также преподает Microsoft и рекомендованное Microsoft соглашение об именах: msdn.microsoft.com/en-us/library/ms124456(v=SQL.100).aspx
asus3000

10

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

Префикс :

  • 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

4
Теперь есть интересный взгляд на приставку. Похоже, это хороший способ разделить звездочки по их использованию.
DOK

10

TableName_WhatItDoes

  • Comment_GetByID

  • Customer_List

  • UserPreference_DeleteByUserID

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

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


Отделить элементы «z» от остальных - отличная идея.
DOK

Мне нравится этот метод. Их должно быть легко найти. Когда я просматриваю список первых sprocs глаголов и вижу 200 Gets, 200 Inserts, 200 обновлений, трудно найти все для конкретной таблицы или группы. Сначала я использовал метод глагола, и он быстро превратился в беспорядок. Имя таблицы сначала решает эту проблему. Так, например, выше в ответе все ваши комментарии или комментарии клиентов будут сгруппированы вместе, чтобы их было легко найти.
Astrosteve

1
А что, если у вас есть запрос, объединяющий несколько таблиц?
leandronn

10

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

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


2
Именование sprocs «sp_» также является очень плохой идеей для скорости, потому что SQL Server пытается оптимизировать поиск для тех, которые основаны на предположении, что они являются системными процедурами. Посмотрите здесь, 5-я точка вниз: rakph.wordpress.com/2008/04/19/tips-store-procedure
Ant

4

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

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


Пакеты хорошие. Начиная с SQL Server 2005, Management Studio позволяет создавать «решения» для хранения связанных sprocs и других операторов SQL.
DOK,

2
@DOK - обратите внимание, что эти пакеты не имеют места в самой базе данных. Это чисто артефакты интерфейсного инструмента. Вы не можете выполнять запросы по пакетам в словаре данных. Пакеты Oracle являются объектами первого класса в словаре системных данных и имеют свою собственную область действия.
ConcernedOfTunbridgeWells

4

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

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

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


Да, особенно спасибо за использование сокращений.
DOK

@ [DOK]: пожалуйста - что, без голосов? ;-)
Стивен А. Лоу

Стив, ты проголосовал за. Я был слишком занят чтением множества ответов и комментариев и мучительно размышлял о том, какой ответ «лучший».
DOK

@ [DOK]: спасибо; «лучший» ответ - это, вероятно, комбинация, которая имеет смысл в вашей ситуации.
Стивен А. Лоу

4

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

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

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

Пример:

P_CMS_USER_UserInfoGet

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

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

2

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

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

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

  • uspUserCreate
  • uspUserSelect
  • uspUserSelectByNetworkID

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

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


2

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

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

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

например

wmt_ ins _ customer _details

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

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

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

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

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


Я вообще ненавижу использование подчеркивания, но способ его использования - не только для разделения префикса, но и для разделения операции - упростит поиск при сканировании списка из сотен sproc. Pretty_neat_idea.
DOK

2

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

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

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

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


1

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

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


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

1

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

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

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

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

shopGetCategories
shopUpdateItem

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

1

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

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

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

spu_archiveCollectionData 

или

spu_setAwardStatus

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

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


spu_, интересно. Избегает проблемы SQL Server sp_.
DOK,

1

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

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

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


1

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

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

Для получения данных: 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

Интересный. Я никогда не видел, чтобы это делалось таким образом, но правильные названия легко запомнить или угадать.
DOK

1
Спасибо, ДОК, да, его легко запомнить, и мы, разработчики, не чувствуем никаких сложностей в именах
Гаурав Арораа,

9
Почему не _C _R _U _D?
однажды, когда

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

1
Префикс sp_ использовать не рекомендуется.
Piyey
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.