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

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

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

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

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

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

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

InsertSalesOrder PopulateItemStagingTables CalculateOrderSummary PrepareCustomerStatements

и т. Д.

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

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

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

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

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

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

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

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

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

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

Это может помочь. Поскольку я программист на 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

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

    InsertUser
    UpdateUser
    DeleteUser
    GetUsers

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

    AppName_User_GetUser
    AppName_User_InsertUser
    AppName_User_UpdateUser
    AppName_User_DeleteUser

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

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

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

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

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

Например: ProcessMathEquationWithFieldIdPlantId

Я считаю, что это поможет немедленно предоставить информацию всем, кто ее использует.

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