Это плохой способ структурировать мою базу данных Sql Server?

Question

У меня есть таблица, которая содержит несколько столбцов, а затем 2 заключительных (обнуляемых) столбца, которые являются varbinary (на самом деле, они являются типами географии SQL 2008, но я хочу сохранить эту независимость от базы данных).

Я набрал около 500 МБ с 200К строк. Проблема в varbinary - и мне нужны данные.

Итак, мне было интересно, если это плохо, если я сделаю следующее: -

• Создание отдельной FILEGROUP: SpatialData.mdf
• Создать новую таблицу, назначенную этой новой файловой группе.
• Переместить все пространственные данные (читай: последние два поля) из исходной таблицы в новую таблицу. Новая таблица имеет внешний ключ к исходной таблице.
• Создание представления, представляющего обе таблицы.

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

EG.

Оригинальный стол

FooId INT PK NOT NULL IDENTITY
Blah VARCHAR(..) NOT NULL
Boo WHATEVER NOT NULL

Новая таблица

FooID PK FK NOT NULL
Spatial_A VARBINARY(MAX)/GEOGRAPHY
Spatial_B VARBINARY(MAX)/GEOGRAPHY

Причина, по которой я хочу знать, если это плохо, заключается в представлении и в том, как представление выполняет объединение в пространственной таблице. Я буду часто использовать вид. В настоящее время я просто делаю запросы к исходной таблице (потому что новая таблица еще не существует). При добавлении этого соединения и отношений PK / FK это повлияет на производительность?

Зачем разбивать данные? Мне нужно время от времени загружать живую БД на наши серверы разработки. На самом деле мы не слишком заботимся об этих двух пространственных полях, поэтому не иметь их хорошо. Поэтому размер загружаемой базы данных будет намного меньше.

Мысли

Answer 1

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

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

Answer 2

Вместо создания второй таблицы, объединения и создания представления лучшее решение, которое возможно в SQL Server 2005/2008, - это использование разбиения таблиц. Насколько я помню, вы можете разделить таблицу по вертикали и поместить некоторые столбцы (т.е. ваши геопространственные столбцы) в одну файловую группу, а остальные поместить в другую файловую группу. SQL Server позаботится обо всем остальном, вам не нужно беспокоиться об объединении, и вам не нужно представление.