Именование хранимых процедур SQL Server

11

Мы начали называть наши хранимые процедуры как [16_TestStoredProc]. Есть ли какие-либо последствия присвоения имен хранимой процедуре?

Я не собираюсь объяснять, почему мы это делаем. Это не то, что у меня есть проблемы с этим, но будет иметь какие-либо последствия.

Джошуа
источник
11
Спасибо за тестирование для всех нас всех инструментов, которые ломаются с именами без кавычек :)
Remus Rusanu
2
Спасибо сообществу за то, что он не задал этот вопрос, говоря не настоящий вопрос . Я уверен, что это поможет будущим читателям понять последствия использования различных соглашений об именах.
Ануй Трипати,
5
Было бы интересно узнать, почему вы это делаете.
Макс Вернон,
2
Я рекомендую называть ваши хранимые процедуры с помощью шаблона «NounVerb». Примерами являются «EmployeeGetAll» и «EmployeeInsert». Это сохраняет все ваши связанные хранимые процедуры отсортированными.
user2023861
1
Это не похоже на то, что это может быть очень полезным решением для ваших программистов или для долгосрочного обслуживания. Обычно я использую шаблон VerbNoun, например GetEmployee, который не объединяет все процедуры Employee, как это делает NounVerb, но он гораздо более интуитивно понятен.
Дэвид Т. Макнет

Ответы:

25

Там нет никаких технических проблем с этим.

Это не будет иметь никакого значения для SQL Server.

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

exec some_schema.16_TestStoredProc

не будет действительным, и вы всегда должны использовать

exec some_schema.[16_TestStoredProc]

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

Я не собираюсь объяснять, почему мы это делаем

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

Мартин Смит
источник