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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Надеется, что это помогает

Answer 6

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

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

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

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

Answer 7

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

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