Кто-нибудь может порекомендовать стандарты кодирования для TSQL?

9

У нас уже давно есть стандарты кодирования для нашего кода .Net, и, похоже, существует несколько авторитетных источников идей о том, как их применять, которые развиваются с течением времени.

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

Роуланд Шоу
источник
1
Пинал Дэйв имеет список стандартов кодирования на своем сайте . Они выглядят как справедливая основа для набора стандартов.
Будет ли
1
Есть связанный вопрос по SO .
Скотт Уитлок
1
@ Скотт, который охватывает только идентификацию; ничего о присвоении имен, использовании курсоров / хранимых процедур / выбора типа данных или чего-либо, что действительно влияет на качество кода ...
Роуланд Шоу,
1
именно поэтому, следовательно, я сказал, что это «связано», а не «дубликат».
Скотт Уитлок

Ответы:

6

По моему опыту, основные вещи, которые я бы искал, были бы:

  • Имена таблиц и столбцов - посмотрите, используете ли вы ID, номер ссылки или номер для столбцов типа ID, единственное или множественное число для имен (множественные числа являются общими для имен таблиц - например, THINGS, единственное число для имен столбцов - например, THING_ID). Для меня наиболее важными здесь являются последовательность, которая позволяет избежать потери времени людьми (например, вы не сталкиваетесь с опечатками, когда кто-то помещает THING в качестве имени таблицы, потому что вы просто интуитивно знаете, что имена таблиц никогда не бывают единичными).

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

  • При выборе, обновлении, вставке и удалении должно быть указано одно имя столбца, одно имя таблицы и один пункт предложение / порядок за предложением на строку, чтобы их можно было легко комментировать по одному во время отладки.

  • Префикс для типов объектов, особенно там, где они могут быть запутаны (поэтому v для представления является наиболее важным). Не уверен, что он все еще применяется, но он был неэффективным для хранимых процедур, кроме системных процедур, для начала sp_. Вероятно, лучшая практика для их различения - это то, что я использовал совсем недавно.

  • Стандарт, указывающий, как имя триггера должно включать, для него ли это обновление / вставка / удаление и таблицу, к которой он относится. У меня нет предпочтительного стандарта, но это важная информация, и ее легко найти.

  • Стандарт для владения объектами в более ранних версиях SQL Server или схеме, в которой он должен существовать на 2005 г. и позднее. Это ваш вызов, что это такое, но вы никогда не должны догадываться, кто чем-то владеет / где он живет) и, где возможно, схема / владелец должны быть включены в сценарии CREATE, чтобы минимизировать вероятность того, что это будет создано неправильно.

  • Показатель того, что любому, кто пользуется SELECT *, будет предложено выпить пинту собственной мочи.

  • Если нет действительно очень веской причины (которая не включает в себя лень с вашей стороны), имейте, применяйте и поддерживайте отношения первичный ключ / внешний ключ с самого начала. В конце концов, это реляционная база данных, а не плоский файл, и осиротевшие записи в какой-то момент сделают вашу жизнь поддержки адом. Также имейте в виду, что если вы не сделаете это сейчас, я могу обещать вам, что вам никогда не удастся реализовать его после события, потому что это в 10 раз больше работы, если у вас есть данные (что будет немного облажаться, потому что вы никогда не применяете отношения правильно).

Я уверен, что что-то упустил, но для меня это те, которые действительно предлагают реальную выгоду в приличном количестве ситуаций.

Но, как и во всех стандартах, меньше значит больше. Чем дольше ваши стандарты кодирования, тем меньше вероятность, что люди будут их читать и использовать. Как только вы пройдете пару хорошо разнесенных страниц, начните искать то, что на самом деле не имеет практического значения в реальном мире, потому что вы просто уменьшаете вероятность того, что люди сделают что-либо из этого.

РЕДАКТИРОВАТЬ: два исправления - в том числе схемы в разделе владения, удаление ошибочной подсказки о количестве (*) - см. Комментарии ниже.

Джон Хопкинс
источник
1
Какой-то странный выбор ... "ВЫБЕРИТЕ СЧЕТЧИК (*)" плохо? Вы когда-нибудь слышали о схемах (которые не совпадают с владельцем)? Ваши другие хороши, хотя
gbn
1
@ Джон Хопкинс - я знаю, почему плохо использовать SELECT *. Было бы здорово, если бы вы могли сказать, почему использование SELECT COUNT (*) плохо.
k25
1
@gbn @ k25 - Несколько лет назад (2002?) у меня был администратор базы данных, который был очень горячим по счету (*), но гуглил в ответ на ваши вопросы, кажется, что это уже устарело (если это когда-либо было правдой). sqlservercentral.com/articles/Performance+Tuning/adviceoncount/… (требуется регистрация). Прежде всего, она была администратором базы данных Oracle, поэтому, возможно, это была настоящая проблема, которая, как она полагала, была и проблемой для оптимизатора SQL.
Джон Хопкинс
1
@gbn - Да, хотя я был относительно невмешателен, так как они были представлены, поэтому моя автоматическая реакция была пользователями. Я обновлю ответ, чтобы покрыть схемы.
Джон Хопкинс
1
@gbn, @ k25 - Больше копать на счету (*). Очевидно, это была проблема в Oracle 7 и более ранних версиях, исправленная в 8i и более поздних версиях. Неясно, была ли это когда-либо проблема в SQL Server, но, конечно, больше нет. Кажется, мой DBA устарел.
Джон Хопкинс
3

Кажется, что нет никаких ресурсов для консенсуса относительно того, что определяет хорошо написанный SQL

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

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

Ларри Коулман
источник
1
+1. Я думаю, что самое главное, что у вас есть последовательность в вашей команде.
Дин Хардинг
1
из интереса, что бы вы сделали по-другому? Это в основном вопросы вкуса (макет и т. Д.) Или есть какие-то "серьезные" ошибки?
Джон Хопкинс
1
@Jon: никаких серьезных ошибок, только субъективные вещи, такие как имена таблиц в единственном числе, ненависть к триггерам и т. Д. Кстати, «SELECT *» - это хорошо внутри «EXISTS ()».
Ларри Коулман
1
Яркий пример (и я использую его с EXISTS и не заставляю себя пить мочу).
Джон Хопкинс
1

В дополнение к ответу Джона Хопкинса ...

  • Отдельные внутренние и внешние объекты

    • IX, UQ, TRG, CK и т. Д. Для ограничений и индексов и т. Д.
    • нижний регистр или CapsCase для клиента, например, uspThing_Add
  • Для внутренних объектов сделайте их явными, если «не по умолчанию»

    • UQ = уникальное ограничение
    • UQC = уникальное кластеризованное ограничение
    • PK = первичный ключ
    • PKN = некластерный первичный ключ
    • IX = индекс
    • IXU = уникальный индекс
    • IXC = кластерный индекс
    • IXCU или IXUC = уникальный кластерный индекс
  • Используйте схемы для упрощения именования + разрешения. Примеры:

    • Helper.xxx для внутренних проц
    • HelperFn.xxx для udfs
    • WebGUI.xxx для некоторого кода
    • Данные и / или история и / или подготовка для таблиц
ГБН
источник