Какова наилучшая практика именования хранимых процедур для t-sql?

Question

Я работал с несколькими большими базами данных, и имена хранимых процедур были очень разными:

SP_PrefixXXX
PrefixYyyXxx
Prefix: Rep, Act

Какова лучшая практика именования? Как я могу организовать их должным образом?

Answer 1

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

Кроме этого, вы можете сами составить любое соглашение об именах. Один используется нашей компанией subsystem_object_action, например main_Customer_Get. Это ставит процедуры, которые принадлежат друг другу, близко друг к другу в листинге.

Answer 2

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

    InsertUser
    UpdateUser
    DeleteUser
    GetUsers

Я делаю это так:

    AppName_User_GetUser
    AppName_User_InsertUser
    AppName_User_UpdateUser
    AppName_User_DeleteUser

Я считаю, что мне легче управлять в моем приложении для управления SQL и в моем коде тоже.

Как говорили другие люди, не используйте префикс sp_

Answer 3

Наилучшим соглашением об именах является то, которое согласовано в вашей базе данных:)

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

Я стараюсь избегать sp_, usp_ и тому подобного, потому что считаю их излишними. Например, sproc с именем InsertCustomer явно является sproc, и его никоим образом нельзя спутать с таблицей, представлением или любым другим видом объекта. В частности, sp_ следует избегать.

Я предпочитаю CamelCase, но опять же, это вопрос предпочтений. Мне нравится, что имя моего процесса дает хорошее представление о том, что делает этот процесс, например:

InsertSalesOrder PopulateItemStagingTables CalculateOrderSummary PrepareCustomerStatements

и т.д.

Answer 4

Я не знаю, есть ли в этом случае конкретная «лучшая практика». Для компании, в которой я сейчас нахожусь, стандартом является usp [имя_процесса] (без подчеркивания). Лично я бы предпочел вообще не использовать префикс, но если вы новичок в компании или проекте, и у них есть уже существующие стандарты, если они не используют sp_, где есть техническая причина не использовать это, это, вероятно, вопрос стоит обсудить, поскольку я, конечно, не думаю, что это в данном случае вообще вопиющий стандарт.

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

Answer 5

Не "sp_" и не "usp_". Мы знаем это хранимые процедуры, схема именования нам не нужна.

Обычно я просто называю их тем, что они делают, возможно, разбивая их на схемы. Исключением является то, что я буду использовать префикс «ssis_» для хранимых процедур, которые непосредственно не используются как часть «обычных» операций с базой данных, но которые используются пакетом служб SSIS для ссылки на базу данных. Я могу использовать «fn_» для обозначения функции, чтобы отличить ее от хранимой процедуры.

Answer 6

Ну, префикс имени с "SP_" в значительной степени избыточен: он называет реализацию (это SP, а не таблица или представление). Существует множество других способов (systebales, information_schema, как вы их используете), которые сообщат вам, как это реализовано.

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

Но, опять же, назовите его для , что он делает , а не , как это происходит при реализации .

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

Answer 7

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

Например: ProcessMathEquationWithFieldIdPlantId

По-моему, это поможет незамедлительно дать информацию любому, кто ее использует.

Я также избегаю sp_ и usp_, чтобы ограничить любую вероятность конфликтов имен.

Answer 8

Это может помочь. Поскольку я программист на front / backend, я использую следующее для MySQL и SQLServer:

SPx_PAGE/MODULE_ACTION_OBJECT 

x: R для чтения, I для вставки, U для обновления, W для записи (объединяет вставку, если индекс не существует, или обновление, если существует) и D для удаления.

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

Примеры:

SPR_DASHBOARD_GET_USERS //reads users data
SPW_COMPANIES_PUT_COMPANY //creates or modifies a company

Answer 9

Лучше создать схему для отдельного модуля.

Тогда дайте значимое и простое имя.

Например: если вы работаете в школьном проекте.

создать студент схема

имя процедуры: AddStudent

Так будет выглядеть Student.AddStudent в списке процедур

то же самое для модуля учителя

Answer 10

Я не профессионал, но мне нравится этот способ

Префикс приложения = XY; View = v; Хранимая процедура = p; Функция = F

Table: XY_Name
View: vXY_Name
Procedure: sXY_Name
Function: fXY_Name

Что ты думаешь? Я знаю, что некоторые люди используют два символа для идентификации типа объекта, но одного символа достаточно для большинства случаев, верно?