Имена таблиц и столбцов - посмотрите, используете ли вы ID, номер ссылки или номер для столбцов типа ID, единственное или множественное число для имен (множественные числа являются общими для имен таблиц - например, THINGS, единственное число для имен столбцов - например, THING_ID). Для меня наиболее важными здесь являются последовательность, которая позволяет избежать потери времени людьми (например, вы не сталкиваетесь с опечатками, когда кто-то помещает THING в качестве имени таблицы, потому что вы просто интуитивно знаете, что имена таблиц никогда не бывают единичными).
Все создания должны включать отбрасывание (в зависимости от существующего объекта) как часть их файла. Вы также можете включить разрешение на получение гранта, до вас.
При выборе, обновлении, вставке и удалении должно быть указано одно имя столбца, одно имя таблицы и один пункт предложение / порядок за предложением на строку, чтобы их можно было легко комментировать по одному во время отладки.
Префикс для типов объектов, особенно там, где они могут быть запутаны (поэтому v для представления является наиболее важным). Не уверен, что он все еще применяется, но он был неэффективным для хранимых процедур, кроме системных процедур, для начала sp_. Вероятно, лучшая практика для их различения - это то, что я использовал совсем недавно.
Стандарт, указывающий, как имя триггера должно включать, для него ли это обновление / вставка / удаление и таблицу, к которой он относится. У меня нет предпочтительного стандарта, но это важная информация, и ее легко найти.
Стандарт для владения объектами в более ранних версиях SQL Server или схеме, в которой он должен существовать на 2005 г. и позднее. Это ваш вызов, что это такое, но вы никогда не должны догадываться, кто чем-то владеет / где он живет) и, где возможно, схема / владелец должны быть включены в сценарии CREATE, чтобы минимизировать вероятность того, что это будет создано неправильно.
Показатель того, что любому, кто пользуется SELECT *, будет предложено выпить пинту собственной мочи.
Если нет действительно очень веской причины (которая не включает в себя лень с вашей стороны), имейте, применяйте и поддерживайте отношения первичный ключ / внешний ключ с самого начала. В конце концов, это реляционная база данных, а не плоский файл, и осиротевшие записи в какой-то момент сделают вашу жизнь поддержки адом. Также имейте в виду, что если вы не сделаете это сейчас, я могу обещать вам, что вам никогда не удастся реализовать его после события, потому что это в 10 раз больше работы, если у вас есть данные (что будет немного облажаться, потому что вы никогда не применяете отношения правильно).
Я уверен, что что-то упустил, но для меня это те, которые действительно предлагают реальную выгоду в приличном количестве ситуаций.
Но, как и во всех стандартах, меньше значит больше. Чем дольше ваши стандарты кодирования, тем меньше вероятность, что люди будут их читать и использовать. Как только вы пройдете пару хорошо разнесенных страниц, начните искать то, что на самом деле не имеет практического значения в реальном мире, потому что вы просто уменьшаете вероятность того, что люди сделают что-либо из этого.
РЕДАКТИРОВАТЬ: два исправления - в том числе схемы в разделе владения, удаление ошибочной подсказки о количестве (*) - см. Комментарии ниже.