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

Ответ 1

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

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

Ответ 2

Лучшее соглашение об именах - это то, что соответствует вашей базе данных:)

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

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

Я предпочитаю CamelCase, но опять же, это вопрос предпочтения. Мне нравится мое имя proc, чтобы дать хорошее представление о том, что делает proc - например:

InsertSalesOrder PopulateItemStagingTables CalculateOrderSummary PrepareCustomerStatements

и др.

Ответ 3

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

    InsertUser
    UpdateUser
    DeleteUser
    GetUsers

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

    AppName_User_GetUser
    AppName_User_InsertUser
    AppName_User_UpdateUser
    AppName_User_DeleteUser

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

Как и другие люди, не префикс sp_

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

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

Например: ProcessMathEquationWithFieldIdPlantId

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

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

Ответ 8

Я не про, но мне нравится этот путь

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

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

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

Ответ 9

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

Затем укажите значащее и простое имя.

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

создать Студенческую схему

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

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

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

Ответ 10

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

SPx_PAGE/MODULE_ACTION_OBJECT 

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

page/module: место, которое вызывает процедуру

Примеры:

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