SQL Server 2008, присоединиться или нет присоединиться?

Question

Просто небольшой вопрос по поводу объединений. У меня есть таблица с 30 полями, и я думал о создании второй таблицы для хранения 10 из этих полей. Тогда я бы просто присоединился к ним с основными данными. 10 полей, которые я планировал сохранить во второй таблице, не запрашиваются напрямую, это всего лишь некоторые настройки для данных в первой таблице.

Что-то вроде:

Table 1
Id
Data1
Data2
Data3
etc ...

Table 2
Id (same id as table one)
Settings1
Settings2
Settings3

Это плохое решение? Должен ли я просто использовать одну таблицу? Насколько это влияет на производительность? Все записи в таблице 1 также будут иметь запись в таблице 2.

Небольшое обновление в порядке. Большинство полей данных имеют тип varchar, а 2 из них имеют текстовый тип. Как лечится индексация? Мой план состоит в том, чтобы проиндексировать 2 поля данных, электронную почту (varchar 50) и автора (varchar 20). И да, все записи в таблице 1 будут иметь записи в таблице 2. Большинство полей настроек имеют битовый тип, около 80%. Остальное - смесь между int и varchar. Varchars могут быть нулевыми.

Answer 1

Это будет зависеть от того, нужна ли каждой строке в таблице 1 строка в таблице 2 (есть ли в каждой строке настройки) и от того, сколько из этих настроек регулярно равно NULL.

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

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

Answer 2

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

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

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

Answer 3

Вы неплохое решение, но подумайте о следующих вещах:

1. Таблица, содержащая большее количество столбцов и во многих из них хранится ноль, является признаком для создания другой таблицы
2. Если вы хотите сохранить настройки, создайте дизайн, который может хранить любое количество настроек без сохранения нулевого значения, например, создайте таблицу, имеющую поля, primarykeyid, foreignkeyid, settingname, settingvalue. Обратите внимание, что в 2 вы сохраняете заголовок имени параметра, но используете int или tiny int, это будет работать намного лучше.

Надеюсь, это поможет

Answer 4

Если данные принадлежат друг другу, держите их вместе.

Если ваши настройки не имеют смысла без данных основной таблицы и соответствуют им один к одному (т. Е. Одна строка в таблице 1 содержит ровно одну строку таблицы 2), то вам следует добавить их в основную таблицу.

Answer 5

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

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

Answer 6

Размер полей, частота и тип использования (выборки, обновления и т. Д.) И размер таблиц (строк) имеют значение, в дополнение к способам их индексации.

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

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

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

Answer 7

У таблиц 1 и 2 одинаковое количество строк? То есть каждая строка в таблице 1 имеет соответствующую строку в таблице 2, и наоборот? Если это так, объединение не нужно, вы можете просто отфильтровать нужные столбцы с помощью выбора.

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

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