Упорядочение столбцов в таблицах базы данных

Question

Когда речь идет о порядке столбцов в таблицах БД, существуют ли какие-либо стандарты или, по крайней мере, лучшие практики?

Вот соглашение ручной работы, которому я следую:

• первичный ключ (т. Е. id);
• уникальные столбцы (т.е. email, ssn);
• внешние ключи (т.е. article);
• столбцы, содержащие пользовательские данные (т.е. first_name, last_name);
• столбцы, содержащие данные, сгенерированные системой;
  • не булево (т.е. password_hash);
  • логическое значение (т. Е. deleted, verified)
• столбцы меток времени (т.е. created_at);

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

Answer 1

Короче говоря, вы хорошо изложили стандартные соглашения и вы не пропустите много . ИМО, единственный шаг, который заставил бы кого-то выглядеть непрофессионально, был бы не иметь Первичный Ключ (и) сначала Получение внешних ключей сразу после этого - хорошее соглашение, но не большое дело. (Первичные ключи с несколькими полями, которые включают внешние ключи, конечно, должны быть в самом начале, или кто-то должен быть избит.) Я бы добавил две дополнительные мысли:

1. Есть поля с похожими темами рядом друг с другом. Например, иметь широкое разделение полей City / State / Zip было бы бесполезно. Я думаю, что ни в коем случае не имеет значения, кто первым пришел user_role или user_ip, но они звучат так, как будто они должны быть рядом друг с другом.
2. Вторично к другим подобным соглашениям, это не повредит алфавитным вещам.

Наличие дополнительных соглашений в вашей базе данных - очень хорошая идея (как, как вы упомянули, всегда иметь отметку времени в конце). Если у вас есть поля ChangeDate и ChangeBy во многих ваших таблицах, хорошо иметь их (удобно расположенные рядом друг с другом и) последовательно.

Дополнительно, ErikE упомянул, что может быть некоторая эффективность в наличии в конце таблицы полей переменной длины (varchar, nvarchar), которые часто могут содержать нули. Кроме этого, я не думаю, что есть какие-то преимущества в производительности для организации вещей определенным образом в современных реляционных базах данных.

Нейминг

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

Answer 2

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

Доказательство конечных значений NULL, уменьшающих объем хранилища, можно получить на Расшифровка страницы данных SQL Server :

... Нулевое растровое изображение немного отличается (fe / 1111 1110), так как сейчас второй столбец нулевой. какой Интересно, что в этом ряду только один столбец переменной длины настоящее, а не два. Таким образом, есть только конец столбца одной переменной длины идентификатор индекса, 0d00 / 0x000d / 13. Из этого можно сделать вывод, что столбцы обрабатываются по порядку, и, таким образом, один может захотеть рассмотреть порядок столбцы, если конкретный столбец обычно ноль, это может быть больше эффективно, чтобы он был заказан последним.

Обратите внимание, что это относится только к столбцам переменной длины. Хотя это явно включает varchar, varbinary и т. Д., Я не уверен насчет других типов данных (и сейчас у меня нет времени, чтобы окончательно это определить).

Answer 3

В MS Sql Server типы данных ntext, image и text (все устаревшие) должны быть последними столбцами в строке, чтобы избежать снижения производительности.

Answer 4

вы можете найти различные лучшие практики по всей сети.

Всегда сохраняйте операторы CREATE TABLE, наряду со всеми другими заявлениями определение схемы базы данных в безопасном место нахождения. Каждый раз, когда вы вносите изменения к объекту базы данных, обязательно Сценарий изменения и проверить его в программное обеспечение для контроля версий, такое как Visual Source Safe.

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

Хотя описательные имена таблиц имеют нет преимуществ в производительности. Они делают базы данных самодокументируются и проще кодировать против. Имена таблиц должны отражать их бизнес-значение.

Создание пользовательских таблиц на неосновных файловая группа; зарезервировать основной файл группа для системных объектов. Таким образом, система поставляется и определяется пользователем объекты не конкурируют за диск ресурсы.

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

Создание кластеризованного индекса на каждом Таблица. Каждая таблица может иметь только единый кластерный индекс. Если стол имеет кластерный индекс, его данные физически отсортированы в соответствии с ключ кластеризованного индекса. Кластерные индексы В SQL Server есть множество преимуществ. Например, если вы получаете данные из таблица с использованием предложения ORDER BY ссылка на ключ кластеризованного индекса, данные не нужно сортировать по время выполнения запроса.

Если две таблицы имеют общий столбец, например customer_id, и оба таблицы имеют кластерные индексы на столбец customer_id, такой столов будет значительно больше эффективнее, чем объединять одни и те же таблицы на основе того же столбца, но без кластерные индексы.

Убедитесь, что кластерный индекс построен на столбец, который содержит различные

Источник: Создание таблиц SQL Server: руководство по оптимальным методам