Редкое ограничение размера столбца обходное решение

Question

Я использую SQL-сервер 2014. Я создаю несколько таблиц, всегда с более чем 500 столбцами, которые будут меняться соответственно.

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

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

Я знаю, что SQL-сервер позволяет только 8 Kb данных подряд, мне нужно знать, для чего это работает. Если мне нужно планировать переход на No SQL (Mongodb), какое влияние это будет оказывать на преобразование моей хранимой процедуры.

Answer 1

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

В любом случае, есть limit of 8060 bytes per row, поэтому редкие столбцы не помогут.

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

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

Например, у вас есть Table1 с колонкой ID (который является основным ключом) и 1000 других столбцов. Разделите его на Table1 и Table2. Каждый из них будет иметь одинаковый ID в качестве первичного ключа и по 500 столбцов. Таблицы будут связаны 1: 1 с использованием ограничения внешнего ключа.

Answer 2

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

Посмотрите, сколько вы можете преобразовать из статических типов в переменные длины (varchar, nvarchar, varbinary). Это может купить вам дополнительное пространство на странице, поскольку поля переменной длины могут быть помещены в страницы переполнения, но несут накладные расходы на 24 байта для указателя на страницу переполнения. Я подозреваю, что вы думаете, что разреженные столбцы позволят вам хранить столбцы 30K ... это было бы только тем обстоятельством, когда у вас была широкая таблица, где большая часть столбцов имеет значение NULL.

MongoDB не будет вашим ответом ... по крайней мере, не без большого количества рефакторинга. Вы не сможете использовать существующие хранимые процедуры. Это может быть лучше всего подходит вам, но есть много вещей, которые следует учитывать при переходе на MongoDB. Ваш уровень доступа к данным нужно будет перестроить, если только вам не удастся сохранить ваши данные в реляционной структуре как документы JSON :). Я предполагаю, что это не так.

Я предполагаю, что у вас широкие столы, и они густо заселены ... исходя из этого предположения, вот моя рекомендация.

Разделите таблицу, как предложил Владимир, но создайте представление, которое объединит все эти таблицы, чтобы оно выглядело как одна таблица.Теперь у вас такая же структура, как и раньше. Затем добавьте вместо представления триггер в представление, чтобы обновить таблицы. Это способ, которым вы можете получить то, что хотите, без необходимости выполнять основной рефакторинг кода. Существует код, который нужно добавить для триггера, но мой опыт в том, что его легко написать, и в большинстве случаев я не писал код, но создал сценарий для генерации кода для всех представлений, которые мне приходилось делать, поскольку он повторялся.