SQL Server: любое значение в вертикальном разделении, когда я всегда собираюсь повторно присоединиться к ним? - PullRequest
Новая
       36

SQL Server: любое значение в вертикальном разделении, когда я всегда собираюсь повторно присоединиться к ним?

2 голосов
/ 16 августа 2010

Мне пришлось добавить 64 новых столбца в таблицу, в которой уже было 32 столбца. Для примера: 

Customers
(
    CustomerID int
    Name        varchar(50)
    Address     varchar(50)
    City        varchar(50)
    Region      varchar(50)
    PostalCode  varchar(50)
    Country     varchar(2)
    Telephone   varchar(20)

    ...
    NewColumn1  int null
    NewColumn2  uniqueidentifier null
    NewColumn3  varchar(50)
    NewColumn4  varchar(50)
    ...
    NewColumn64 datetime null

    ...
    CreatedDate datetime
    LastModifiedDate datetime
    LastModifiedWorkstation varchar(50)
    LastModifiedUser varchar(50)
)

Большую часть времени большинство этих новых столбцов будут содержать null.

Также считается, что , если я вертикально разделить эти 64 новых столбца в новую таблицу, то каждый раз, когда я SELECT получаю от клиентов: 

SELECT ...
FROM Customers

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

SELECT ...
FROM Customers
    INNER JOIN Customers_ExtraColumns
    ON Customers.CustomerID = Customers_ExtraColumns.CustomerID

Так что это один con для разделения столбцов.

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

Последнее con , о котором я могу думать, это то, что SQL Server теперь должен выполнять INNER JOIN каждый раз, когда я хочу получить доступ к " Customers ". Теперь и навсегда тратятся ресурсы процессора и ввода-вывода для объединения таблиц, которые на самом деле представляют собой одну таблицу - за исключением того, что я решил разделить их.

Итак, мой вопрос: зачем мне их разделять?

Есть ли какое-либо значение в вертикальном разбиении 64 столбцов в отдельной таблице, когда они в основном будут нулевыми? Null занимают очень мало места ....

Какие плюсы?

Редактировать: Почему я даже рассматриваю разделение? В основном это нулевые данные, которые утроят количество столбцов в таблице. Конечно это должно быть плохо!

Ответы [ 3 ]

2 голосов
/ 17 августа 2010

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

Однако, некоторые моменты:

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

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

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

1 голос
/ 17 августа 2010

Ответ в деталях, которые были опущены в вопросе. Количество столбцов не имеет значения, важен характер данных.

  • Во-первых, помните, что данная строка в любая таблица никогда не может превышать 8060 байт . Так что, если новые столбцы размер такой, что этот предел может теоретически будет превышен, вы будете встроили бомбу замедленного действия в база данных. Когда-нибудь, когда это меньше всего удобно, вставка данных или обновление выдаст ошибку и / или данные потеряться.

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

  • Другое важное соображение данных моделирования. Сделать новые столбцы иметь личные отношения с CustomerID? Например, скажем eyeColor

    Из-за количества столбцов и тот факт, что вы пропустили их имена, я подозреваю, что ненормализованный дизайн рассматривается. Если новые столбцы что-то вроде WebPage1, WebPage2, WebPage3 и т. Д., Затем они должны быть разделены на отдельный нормализованный таблица.
    ,

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

1 голос
/ 16 августа 2010

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

Я пришел из истории EDI, и иногда вам приходится иметь дело с плоскими файлами, которые содержат более 30 столбцов данных в строке. Как вы упоминаете, NULL не занимает много места, и если вы НИКОГДА не будете собирать столбцы независимо друг от друга (и вы никогда не сможете самостоятельно получить базовые данные о клиентах) Я бы сказал, что вы все правильно поняли.

...