SQL Server 2008, соединение или никакое соединение?
Просто небольшой вопрос относительно соединений. У меня есть таблица приблизительно с 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%. Остальное - соединение между интервалом и varchar. varchars может быть пустым.
7 ответов
Это известно как вертикальное разбиение и является допустимой стратегией. Вы можете сделать это по следующим причинам:
- Если к определенным столбцам обращаются или они изменяются гораздо чаще, чем другие.
- Если вы хотите сохранить одни столбцы на одном наборе носителей, а другие - на другом.
- Если у вас есть обширные триггеры, которые не нужно запускать в ответ на обновления в определенных столбцах.
При доступе через JOIN производительность, скорее всего, снизится, но производительность может увеличиться в тех случаях, когда вам нужно получить доступ только к одной или другой из таблиц компонентов.
У таблицы 1 и 2 одинаковое количество строк? То есть каждой строке в таблице 1 соответствует соответствующая строка в таблице 2 и наоборот? Если это так, соединение не требуется, вы можете просто отфильтровать нужные столбцы с помощью выбора.
Соединение будет полезно, только если у вас есть строки в таблице 2, которые соответствуют более чем одной строке в таблице 2, например ряд настроек, которые применяются к нескольким строкам данных.
Редактировать: На мои вопросы уже ответил правка в исходном сообщении. Я бы сказал, что соединение здесь не обязательно и только отрицательно повлияет на производительность.
Если данные принадлежат вместе, храните их вместе.
Если ваши настройки не имеют смысла без данных основной таблицы и соответствуют им однозначно (т.е. одна строка в таблице 1 имеет ровно одну строку - это таблица 2), то вам следует добавить их в основную таблицу.
Это будет зависеть от того, нужна ли каждой строке в таблице 1 строка в таблице 2 (есть ли у каждой строки настройки) и сколько из этих настроек регулярно имеют значение NULL.
Если все настройки (или в основном все) используются и используются регулярно, я бы рекомендовал поместить их в одну таблицу.
Кроме того, количество столбцов, на которые вы ссылаетесь, не является чрезмерным, поэтому я бы порекомендовал использовать одну таблицу без объединения, если используются поля.
Если вы собираетесь регулярно запрашивать таблицу настроек одновременно с таблицей данных, то вам нужно, чтобы они представляли собой единую таблицу. Если вы запрашиваете каждый набор данных отдельно, может быть полезно разделить их.
Производительность снижается при каждом соединении, но вы также хотите посмотреть, как вы используете таблицы. Если они вам нужны одновременно, лучше всего держать их вместе, иначе вы можете разделить их, если не планируете часто использовать их одновременно в будущем.
Ваше решение неплохое, но учтите следующие моменты:
- Таблица, содержащая большее количество столбцов, и многие из них хранят ноль, является признаком создания другой таблицы.
- Если вы хотите сохранить настройки, создайте дизайн, который может хранить любое количество настроек без сохранения null, например создать таблицу с полями, primarykeyid, foreignkeyid, settingname, settingvalue. Обратите внимание, что в 2 вы сохраняете над заголовком имя настройки, но используете int или tiny int, он будет работать намного лучше.
Надеюсь, это поможет
Размер полей, частота и тип использования (выборка, обновление и т. Д.), А также размер таблиц (строк ) имеет значение не только то, как вы его индексируете.
В целом это неплохой дизайн, если подмножество данных в одной таблице просматривается очень часто (например, в списке), а второе подмножество просматривается / редактируется гораздо реже и / или содержит очень большие поля (например, varchar ( Максимум)).
Однако, если данные всегда просматриваются вместе, это, вероятно, не лучший вариант. Поэтому, если вам нужно читать эти настройки во второй таблице каждый раз, когда вы читаете первую таблицу, не идите по этому пути.
Обновление: учитывая ваш индекс и тот факт, что почти все настройки имеют фиксированный размер (бит), я бы просто сделал его одной таблицей. Если вам нужен запрос подмножества без всей таблицы, вы можете рассмотреть покрывающий индекс вместо разделения таблицы.