Конвенції про іменування баз даних від Microsoft?

78

Я знайшов Рекомендації щодо іменування від MSDN, але чи є це рекомендацією щодо бази даних MSSQL від Microsoft?

sql  sql-server  tsql 
— Ченг
джерело
4
Нижче є чудові відповіді, але я хотів би додати наступне: узгодження та дотримання конвенції у вашій організації щодо організації вашої БД (включаючи іменування) є не менш важливими. Наприклад, ми намагаємось спочатку зберегти стовпці первинного ключа, а потім усі стовпці зовнішнього ключа, щоб ви могли швидко знайти взаємозв'язки, а потім усі додаткові стовпці в алфавітному порядку, щоб ви могли знайти той, який ви хочете, коли в таблиці багато тонн стовпців . Мудрість наших конкретних конвенцій спірна, але цінність такої розмови у вашій команді, мабуть, не така.
— bopapa_1979

Відповіді:

181

Правила іменування, що використовуються в базі даних AdventureWorks SQL Server, демонструють багато найкращих практик щодо стилю.

Узагальнити:

  • Назви об’єктів легко зрозуміти
  • Назви таблиць не є множинними (таблиця "Користувач" не "Користувачі")
  • Скорочень мало, але дозволено (наприклад, Qty, Amt тощо)
  • PascalCase використовується виключно за винятком певних імен стовпців (тобто rowguid)
  • Ніяких підкреслень
  • Дозволені певні ключові слова (тобто Ім'я)
  • Збережені процедури мають попередню позначку "usp"
  • До функцій додається "ufn"

Детальніше ви можете знайти тут:

Одне застереження: правила іменування баз даних можуть бути дуже суперечливими, і більшість розробників баз даних, з якими я зустрічався, мають особисту зацікавленість у своєму стилі. Я чув гарячі суперечки щодо того, чи слід називати таблицю "OrderHeader" або "OrderHeaders".

— 8кб
джерело
12
Мені подобається, що ви посилаєтесь на оригінальну статтю, і ДЕЙСТВИТЕЛЬНО люблю те, що ви потрудились підсумувати для всіх. Якби я міг двічі проголосувати.
— bopapa_1979
Шість років потому і все ще отримую +1 за добре викладену відповідь із посиланнями та хорошим резюме.
Яка перевага перед оформленням збереженої процедури та функцій за допомогою uspта ufn? Зберігається процедура, як правило, починається з дієслова, і функція, як правило, має вказане ім'я відповідно до своєї функції.
— ca9163d9
17

Ні, цього немає, але практики у наведеному вами посиланні варто пам’ятати.

Що стосується іменування збережених процедур - не встановлюйте перед ними префікс "sp_". Детальніше про те, чому, ви можете прочитати за цим посиланням :

"Не використовуйте префікс збережених процедур з sp_, оскільки цей префікс зарезервований для ідентифікації системних процедур."

— Поні OMG
джерело
3
Я додав відповідну цитату зі статті, оскільки вона коротка, і ми не можемо сподіватися, що посилання на 5-річну публікацію триватиме вічно.
— Гейб,
1
sp_ не зарезервований, він просто змушує SQL Server шукати системні процедури перед пошуком визначених користувачем процедур.
6

Я не знаю, що означає "найкращі практики з точки зору стилю" у відповіді @ 8kb (на момент написання статті). Безумовно, деякі з перелічених пунктів ("Назви таблиць не множинні", "Без підкреслення" тощо) - це просто вибір стилю, який очевидно є суб'єктивним. Я б подумав, що найбільшими факторами тут будуть особисті уподобання керівника команди документації.

Що стосується евристики в SQL загалом (на відміну від власної SQL, такої як T-SQL), існує лише одна книга на цю тему: Стиль програмування Джо Джо Челко. Багато варіантів вибору бази даних SQL Server AdventureWorks суперечать вимогам Целка.

Конвенція Celko про іменування базується на міжнародному стандарті ISO 11179, наприклад, вказує, що для розділення елементів в назві слід використовувати розмежувальний символ (наприклад, підкреслення). Інші варіанти стилів аналогічно створюють резервні копії досліджень, наприклад, використовуючи виключно малі літери для назв стовпців, щоб допомогти скануванню людським оком. Без сумніву, там теж є суб'єктивні особисті переваги, але вони базуються на багаторічному досвіді в цій галузі.

Позитивом є те, що за останні роки в документах SQL Server все покращилося, наприклад, ключові слова SQL з великими літерами, крапки з комою для відокремлення висловлювань тощо. Пригодницькі роботи - це значне покращення для Northwind та пабів. Чому тепер функція сценаріїв у Management Studio не може виплюнути код, який стає трохи простішим на око ?!

— колись коли
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.