SQL Server — правила анализа схемы/кода — что бы вы включили в свои правила?

Некоторые из моих. Не все можно было протестировать программно:

• Нет префиксов в венгерском стиле (например, «tbl» для таблицы, «vw» для просмотра)
• Если есть шанс, что это когда-либо будет перенесено в Oracle, идентификаторы не должны быть длиннее 30 символов.
• Все имена таблиц и столбцов, представленные только строчными буквами
• Подчеркивания между словами в именах столбцов и таблиц — в этом мы явно различаемся
• Имена таблиц в единственном числе ("клиент", а не "клиенты")
• Слова, из которых состоят имена таблиц, столбцов и представлений, не сокращаются, не объединяются и не основываются на аббревиатурах, если в этом нет необходимости.
• Индексы будут иметь префикс «IX_».
• Первичные ключи имеют префикс «PK_».
• Внешние ключи имеют префикс «FK_».
• Уникальные ограничения имеют префикс «UC_».

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

Если возможно, я бы сообщил о любых таблицах, которые определены как более широкие, чем байты, которые могут быть сохранены в записи (за исключением полей varchar (max) и текстового типа) и/или страницы данных.

Я хочу, чтобы все связанные столбцы PK и FK имели одно и то же имя, если это вообще возможно. Единственный случай, когда это невозможно, - это когда вам нужно иметь два FK в одной таблице, относящейся к одному ПК, и даже тогда я бы назвал его именем ПК и префиксом или суффиксом, описывающим разницу. Например, если бы у меня был PK PersonID и таблица должна была иметь как идентификатор торгового представителя, так и идентификатор клиента, они были бы CustomerPersonID и RepPersonID.

Я бы проверил, чтобы убедиться, что все FK имеют индекс.

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

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

Нет таблицы без определенного уникального индекса или PK. Нет таблицы, в которой ПК представляет собой более одного поля. Нет таблицы, в которой PK не является целым числом.

Нет имен объектов, которые используют зарезервированные слова для базы данных, которую я использую.

Нет полей со словом Дата как часть имени, которые не определены как дата или дата и время.

Нет таблицы без связанной таблицы аудита.

Нет полей с именами SSN, SocialSecurityNumber и т. д., которые не были бы зашифрованы. То же самое для любого поля с именем CreditCardNumber.

Нет пользовательских типов данных (по крайней мере, в SQL Server это создает гораздо больше проблем, чем пользы).

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

Если используется репликация, ни одна таблица без поля GUID.

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

Последовательное использование одного и того же падежа в именовании. Неважно, какой, пока все используют один и тот же.

Нет таблиц с полем ID. Ненавижу их со страстью. Они такие бесполезные. Поля ID должны называться tablenameID, если это PK, и с именем PK, если это FK.

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

Если он также будет анализировать код, я бы хотел увидеть любой код, который использует курсор или коррелированный подзапрос. Зачем создавать проблемы с производительностью с самого начала?

Я хотел бы увидеть, использует ли процедура динамический SQl, и если да, то есть ли у него входная битовая переменная, называемая Debug (и код, который только печатает динамический статус SQl, а не выполняет его, если для переменной Debug установлено значение 1).

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

Я уверен, что мог бы придумать больше.