Существует ли стандарт / соглашение о порядке столбцов в определении таблицы базы данных?

Question

Существует ли стандарт / соглашение о порядке упорядочения столбцов в определении таблицы базы данных, и если да, то какова мотивация для этого стандарта? (плюсы / минусы) * * тысяча один

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

Если существует различие между соглашениями для разных СУБД, СУБД в этом случае будет Microsoft SQL Server 2005.

Спасибо / Эрик

Answer 1

Я не знаю ни одного стандарта, но способ, которым мы структурируем наши столбцы,

1. Первичный ключ (и)
2. Любые внешние ключи
3. Данные

Наши большие столбцы данных, как и комментарии, ставятся в конце. Это позволяет просматривать как можно больше данных в Query Analyzer без необходимости прокрутки вправо.

Answer 2

Я всегда структурирую свои таблицы следующим образом:

1. Первичный ключ (и)
2. столбцы «Отслеживание» (DateModified, ModifiedBy и т. Д.)
3. Любые внешние ключи
4. Данные

Answer 3

Нет официального стандарта, о котором я знаю, но обычная практика - сначала поставить первичный ключ (обычно это суррогат), а затем сгруппировать другие поля по функциональности. Таким образом, в таблице «человек» можно сгруппировать поля, содержащие данные об адресе человека, вместе. Большинство людей добавляют FK, индексы и другие ограничения вне самого определения таблицы.

Answer 4

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

Answer 5

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

Кроме того, это не установленная лучшая практика, а личный выбор.

Answer 6

Согласно edoode: -

Primary key(s) 
'Tracking' columns (DateModified, ModifiedBy and such) 
Any foreign keys 
Data 

Plus

Fixed width 'not null' columns
Fixed width 'nullable' columns
Variable Width columns VARCHAR NVARCHAR etc.
CLOBS
BLOBS 

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

Answer 7

Я согласен с большинством постов выше, первичным ключом первым (как минимум). Остальное личное предпочтение. Если у вас есть стандарт, тогда придерживайтесь этого стандарта.

Я предпочитаю держать столбцы довольно логично вместе. Иногда полностью нормализованная структура данных не подходит, поэтому в одной таблице хранятся «второстепенные объекты» (т.е. не удаляются NULL). Примером могут служить поля адреса или столбцы различных телефонов, мобильных телефонов и рабочих телефонов, размещенные вместе.

Самый яркий пример, который я могу привести, - КАК ЭТО НЕ СДЕЛАТЬ. Если разработчик автоматически генерирует схему, а столбцы создаются в алфавитном порядке (и даже ПК был скрыт в середине структуры таблицы), это НАИБОЛЕЕ раздражает.

Answer 8

мм .. Как я знаю, ограничений нет. Это просто вопрос ясности.