Яка угода про іменування для збережених процедур? [зачинено]

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

Деякі люди префіксують ім'я паростка з usp_, інші - з абревіатурою на ім’я програми, а інші - з прізвищем власника. Не слід використовувати sp_ в SQL Server, якщо ви цього не маєте на увазі.

Деякі починають назву Proc з дієсловом (Get, Add, Save, Remove). Інші підкреслюють найменування юридичних осіб.

У базі даних із сотнями відростків може бути дуже важко прокрутити навколо та знайти підходящий проросток, коли ви думаєте, що такий вже існує. Конвенції про іменування можуть полегшити пошук паростка.

Чи використовуєте ви конвенцію про іменування? Опишіть, будь ласка, і поясніть, чому ви віддаєте перевагу перед іншими варіантами.

Короткий зміст відповідей:

• Всі, здається, виступають за послідовність іменування, що для всіх може бути важливіше використовувати ту саму конвенцію про іменування, ніж та, яка використовується конкретно.
• Префікси: Хоча багато людей використовують usp_ або щось подібне (але рідко sp_), багато інших використовують назву бази даних чи програми. Один розумний DBA використовує gen, rpt та tsk, щоб відрізнити загальні відростки CRUD від тих, які використовуються для звітування або виконання завдань.
• Дієслово + іменник здається дещо популярнішим, ніж іменник + дієслово. Деякі користуються ключовими словами SQL (Вибрати, Вставити, Оновити, Видалити) для дієслів, а інші використовують дієслова, що не належать до SQL (або абревіатури для них), як Get and Add. Деякі розрізняють іменники однини та множини, щоб вказати, чи є одне чи багато записів.
• У кінцевому підсумку, де це доречно, пропонується додаткова фраза. GetCustomerById, GetCustomerBySaleDate.
• Деякі люди використовують підкреслення між сегментами імен, а деякі уникають підкреслення. app_ Get_Customer vs. appGetCustomer - я думаю, це питання читабельності.
• Великі колекції відростків можуть бути поділені на пакети Oracle або рішення та проекти Management Studio (SQL Server) або схеми SQL Server.
• Слід уникати непереборних скорочень.

Чому я обираю відповідь, яку я зробив: Є так багато хороших відповідей. Дякую вам всім! Як бачите, вибрати важко було б дуже важко. Той, кого я вибрав, резонував зі мною. Я дотримувався того ж шляху, який він описав - намагаючись використати іменник Verb +, а потім не в змозі знайти всі відростки, які стосуються Клієнта.

Вміння знайти існуючу паростку або визначити, чи існує навіть така, дуже важливо. Серйозні проблеми можуть виникнути, якщо хтось ненароком створить дублікат проростка з іншим іменем.

Оскільки я, як правило, працюю над дуже великими програмами із сотнями відростків, я віддаю перевагу найпростішому способу пошуку імен. Щодо меншого додатка, я можу виступати за іменник Verb +, оскільки він дотримується загальної норми кодування для імен методів.

Він також виступає за префікс із назвою програми замість не дуже корисного usp_. Як зазначали кілька людей, іноді база даних містить відростки для декількох додатків. Отже, префіксація імені програми допомагає відокремити відростки І допомагає DBA та іншим визначити, для якого додатка використовується паросток.

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

Ось кілька роз'яснень щодо проблеми з префіксом sp_ в SQL Server.

Збережені процедури, названі префіксом sp_, є системними відростками, що зберігаються в базі даних Master.

Якщо ви надаєте цьому парочку цей префікс, SQL Server спочатку шукає їх у базі даних Master, а потім у контекстній базі даних, тим самим без потреби витрачаючи ресурси. І якщо створений користувачем відросток має те саме ім’я, що і парост системи, створений користувачем відросток не буде виконуватися.

Префікс sp_ вказує, що проросток доступний з усіх баз даних, але він повинен бути виконаний у контексті поточної бази даних.

Ось приємне пояснення, яке включає демонстрацію хіта на виставу.

Ось ще одне корисне джерело, надане Ant у коментарі.

Системи угорської мови (як і вище префікс "usp") змушують мене здригатися.

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

Дійсна назва після префікса навряд чи відрізняється від імені функції: зазвичай дієслово типу "Додати", "Встановити", "Створити", "Обчислити", "Видалити" тощо, а потім ще кілька конкретних іменників, таких як "Користувач "," Щоденні доходи "тощо.

Відповідаючи на коментар Мурахи:

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

Я багато років використовував всі різні системи. Нарешті я розробив цей, який я продовжую використовувати сьогодні:

Приставка:

• gen - Загальне: в основному CRUD
• rpt - Доповідь: роз'яснення
• tsk - Завдання: зазвичай щось із процедурною логікою виконайте через заплановані завдання

Специфікатор дії:

Ins - INSERT
Sel - SELECT
Upd - UPDATE
Del - DELETE

(У випадках, коли процедура робить багато речей, загальна мета використовується для вибору специфікатора дії. Наприклад, клієнту INSERT може знадобитися велика підготовча робота, але загальна мета - INSERT, тому вибирається "Ins".

Об'єкт:

Для gen (CRUD) це впливає назва таблиці або перегляду. Для rpt (звіт) це короткий опис звіту. Для tsk (Завдання) це короткий опис завдання.

Необов’язкові роз'яснювачі:

Це необов'язкові біти інформації, яка використовується для покращення розуміння процедури. Приклади включають "За", "За" тощо.

Формат:

[Префікс] [Специфікатор дії] [Суб'єкт] [Необов’язкові уточнювачі]

Приклади назв процедур:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

TableName_WhatItDoes

• Comment_GetByID

• Customer_List

• UserPreference_DeleteByUserID

Ніяких префіксів або дурних угорських дурниць. Просто назва таблиці, з якою вона найбільш тісно пов'язана, і короткий опис того, що вона робить.

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

Починати ім'я збереженої процедури з " sp_SQL Server" погано, оскільки система починає починати з sp_. Послідовне іменування (навіть у міру гобгоблін-дому) корисне, оскільки воно полегшує автоматизовані завдання на основі словника даних. Префікси трохи менш корисні в SQL Server 2005, оскільки вони підтримують схеми, які можна використовувати для різних типів просторів імен так, як раніше використовувались префікси імен. Наприклад, на зірковій схемі можна було мати схеми тьмяності та факту та посилатися на таблиці цієї конвенції.

Для збережених процедур префіксація корисна з метою ідентифікації відростків програми від системних відростків. up_порівняно, sp_дозволяє порівняно легко визначити несистемні збережені процедури зі словника даних.

Я завжди інкапсулює збережені процедури в пакети (я використовую Oracle на роботі). Це зменшить кількість окремих об'єктів і допоможе повторно використовувати код.

Конвенція про іменування - це питання смаку, і ви повинні погодитись з усіма іншими розробниками на початку проекту.

для невеликих баз даних я використовую uspTableNameOperationName, наприклад uspCustomerCreate, uspCustomerDelete тощо. Це полегшує групування за основним об'єктом.

для більших баз даних додайте назву схеми чи підсистеми, наприклад, отримання, придбання тощо, щоб згрупувати їх у групи (оскільки сервер sql любить відображати їх за алфавітом)

Я намагаюся уникати скорочень в іменах, для наочності (і новим людям в проекті не потрібно дивуватися, що означає «UNAICFE», оскільки паросток названий uspUsingNoAbbreviationsIncreasesClarityForEveryone)

Зараз я використовую такий формат, як наступний

Позначення:

[PREFIX] [ЗАЯВКА] [МОДУЛЬ] _ [ІМ’Я]

Приклад:

P_CMS_USER_UserInfoGet

Мені подобається це позначення з кількох причин:

• починаючи з дуже простого префікса дозволяє записати код лише для виконання об'єктів, що починаються з префікса (наприклад, для зменшення ін'єкції SQL)
• У нашому більшому середовищі кілька команд працюють над різними програмами, які працюють в одній архітектурі баз даних. Позначення програми позначає, якій групі належить SP.
• Розділи Модуль та Ім'я просто заповнюють спадковість. Усі імена мають бути в змозі зіставити з групою / додатком, модулем, функцією від спадкоємства.

Я завжди використовую:

usp [Назва таблиці] [Дія] [Докладна інформація]

Враховуючи таблицю під назвою "tblUser", це дає мені:

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

Процедури в алфавітному порядку сортуються за назвою таблиці та за функціональністю, тому легко зрозуміти, що я можу зробити для будь-якої заданої таблиці. Використання префіксу "usp" дає мені знати про те, що я викликаю, якщо я (наприклад) пишу 1000-рядкову процедуру, яка взаємодіє з іншими процедурами, кількома таблицями, функціями, видами та серверами.

Поки редактор SQL Server IDE не настільки гарний, як Visual Studio, я зберігаю приставки.

Операція префікса_ операція префікс_ опис об'єктів бази даних, що беруть участь (мінус пробіли між підкресленнями - повинні були розміщувати пробіли) .

операційні префікси, які ми використовуємо -

• " Отримати " - повертає набір записів
• " Ins " - вставляє дані
• " Upd " - оновлення даних
• " Del " - видаляє дані

напр

wmt_ ins _ customer _details

"інструмент управління робочою силою, вставляйте деталі в таблицю клієнтів"

переваги

Усі збережені процедури, що відносяться до однієї програми, згруповані разом по імені. У межах групи зберігаються процедури, що виконують однакові операції (наприклад, вставки, оновлення тощо).

Ця система добре працює для нас, маючи бл. 1000 збережених процедур в одній базі даних у верхній частині моєї голови.

Наразі у цьому підході не стикалися жодних недоліків.

GetXXX - отримує XXX на основі @ID

GetAllXXX - отримує всі XXX

PutXXX - вставляє XXX, якщо переданий @ID дорівнює -1; інші оновлення

DelXXX - видаляє XXX на основі @ID

Я думаю, що умова про іменування нікому не приносить користі.

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

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

Якби у нас не було обмежень у спадщині, я впевнений, що ми б не використовували префікс.

Після префікса ми зазвичай починаємо ім'я SP з дієслова, яке описує, що робить процедура, а потім імені об'єкта, над яким ми працюємо. Плюралізація назви сутності дозволена. Ми намагаємось підкреслити читабельність, щоб було очевидно, що робить процедура лише від імені.

Типовими збереженими назвами процедур для нашої команди будуть:

shopGetCategories
shopUpdateItem

Я не думаю, що насправді має значення саме те, який ваш префікс такий довгий, поки ви логічні та послідовні. Особисто я використовую

spu_ [опис дії] [опис процесу]

де опис дії - це один із невеликого кола типових дій, таких як отримати, встановити, архівувати, вставити, видалити тощо. Опис процесу - це щось коротке, але описове, наприклад

spu_archiveCollectionData 

або

spu_setAwardStatus

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

Я бачив, як люди намагаються використовувати псевдо-угорські позначення для назви процедур, які, на мою думку, приховують більше, ніж виявляють. Поки, коли я перераховую свої процедури в алфавітному порядку, я можу побачити їх згруповані за функціональністю, то для мене це здається милим місцем між порядком і непотрібною суворістю

Уникайте sp_ * на сервері SQl, оскільки всі збережені в системі prcedures починаються з sp_, і тому системі стає складніше знайти об'єкт, відповідний імені.

Тож якщо ви починаєте з чогось іншого, ніж sp_, речі стають легшими.

Отже, для початку ми використовуємо загальну назву Proc_. Це полегшує ідентифікацію процедур, якщо вони представлені одним великим файлом схеми.

Крім цього, ми призначаємо префікс, який ідентифікує функцію. Подібно до

Proc_Poll_Interface, Proc_Inv_Interface тощо.

Це дозволяє нам знайти всі збережені програми, які виконують роботу POLL проти інвентаризації тощо.

Так чи інакше система префіксів залежить від вашої проблемної області. Але все, що сказав, і щось подібне повинно бути присутнім, навіть якщо це просто для того, щоб люди могли швидко знаходити збережену процедуру в спадному меню Explore для редагування.

інші, наприклад, функції.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Ми слідували за функціонуванням, називаючи coz. Програми схожі на код / ​​функцію, а не на статичні об'єкти, як таблиці. Це не допомагає програмам працювати з більш ніж однією таблицею.

Якщо Proc виконував більше функцій, ніж можна обробляти в одному імені, це означає, що ваш proc робить набагато більше, ніж потрібно, і його час знову розділити їх.

Сподіваюся, що це допомагає.

Я приєднався до кінця теми, але я хочу тут ввести свою відповідь:

У моїх останніх двох проектах є різні тенденції, наприклад, в одному ми використовували:

Отримати дані: s <ім'я табеля> _G
Щоб видалити дані: s <ім'я табелі> _D
Щоб вставити дані: s <ім'я таблиці> _I
оновити дані:

Цю умову іменування також дотримується в передній частині, префіксуючи слово dt .

Приклад:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

За допомогою вищезгаданих конвенцій про іменування у нашому додатку ми маємо хороші та легкі для запам'ятовування імена.

У той час як у другому проекті ми використовували ті самі умови іменування з різницею lll:

Щоб отримати дані: sp_ <ім'я табелі> G
Щоб видалити дані: sp_ <ім'я табелі> D
Щоб вставити дані: sp_ <ім'я табелі> I
Оновити дані: sp_ <ім'я таблиці> U

Приклад:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU