Я подозреваю, что большую часть моего списка было бы трудно поместить в механизм правил, но здесь идет речь:
Если возможно, я бы предоставил отчет о любых таблицах, которые определены как более широкие, чем байты, которые могут быть сохранены в записи (исключая поля varchar (max) и text type) и / или страницу данных.
Я хочу, чтобы все связанные столбцы PK и FK имели одно и то же имя, если это вообще возможно. Единственный случай, когда это невозможно, - это когда вам нужно иметь два FK в одной таблице, относящиеся к одному PK, и даже тогда я назову его именем PK и префиксом или суффиксом, описывающим разницу. Например, если у меня есть PK PersonID и в таблице должны быть указаны и идентификатор торгового представителя, и идентификатор клиента, это будут CustomerPersonID и RepPersonID.
Я бы проверил, чтобы все FK имели индекс.
Я хотел бы знать обо всех полях, которые являются обязательными, но не имеют значения по умолчанию. В зависимости от того, что это, вы можете не захотеть определять значение по умолчанию, но я хотел бы иметь возможность легко увидеть, какие из них не могут найти те, которые должны иметь значение по умолчанию.
Я бы хотел, чтобы все триггеры были проверены, чтобы убедиться, что они основаны на множествах и не предназначены для запуска по одной строке за раз.
Нет таблицы без определенного уникального индекса или PK. Нет таблицы, в которой PK является более чем одним полем. Нет таблицы, в которой PK не является целым.
Нет имен объектов, использующих зарезервированные слова для базы данных, которую я использую.
Нет полей со словом Date как часть имени, которые не определены как date или datetime.
Нет таблицы без связанной таблицы аудита.
Нет полей с именами SSN, SocialSecurityNumber и т. Д., Которые не зашифрованы. То же самое для любого поля с именем CreditCardNumber.
Нет пользовательских типов данных (по крайней мере, в SQL Server это гораздо больше проблем, чем стоит).
Нет представлений, которые вызывают другие представления. Опыт показал мне, что это часто бывает из-за проблем с производительностью. Особенно, если они имеют глубину более одного слоя.
При использовании репликации нет таблицы без поля GUID.
Все таблицы должны иметь поле DateInserted и поле InsertedBy (даже при аудите часто бывает проще исследовать проблемы с данными, если эта информация легко доступна.)
Последовательное использование одного и того же случая в именовании. Неважно, когда все используют один и тот же.
Нет таблиц с полем с именем ID. Ненавижу это со страстью. Они так бесполезны. Поля ID должны иметь имя tablenameID, если PK, и имя PK, если FK.
Нет пробелов или специальных символов в именах объектов. Другими словами, если вам нужна специальная обработка для базы данных, чтобы распознать ее в правильном контексте в запросе, не используйте ее.
Если он также собирается анализировать код, я бы хотел увидеть любой код, который использует курсор или коррелированный подзапрос. Зачем создавать проблемы с производительностью с самого начала?
Я бы хотел посмотреть, использует ли proc динамический SQl и, если да, если у него есть входная битовая переменная Debug (и код для печати только динамического SQl-статута, а не для его выполнения, если переменная Debug установлена в 1) ,
Я бы хотел иметь возможность проверить, что если в базе данных имеется более одного оператора, вызывающего действие (вставка / обновление / удаление), в транзакции также есть явная транзакция и перехват ошибок для откатывания всего объекта назад, если какая-либо часть этого не удалась.
Я уверен, что мог бы придумать больше.