Есть ли для MSSQL решение, позволяющее увидеть статистику по заполнению строковых столбцов данными по сравнению с длиной столбца?
Есть много таблиц в БД со строковыми полями. Какие-то из них nvarchar(max), какие-то имеют ограниченную длину. Это закладывалось в начале разработки, потому что было неизвестно, какой длины будут значения в столбцах.
Сейчас нужно собрать статистику, чтобы понять, насколько длина реальных данных в столбцах отличается от максимального лимита, доступного для этих столбцов, т.е. если в столбце nvarchar(100) самое длинное значение имеет длину 50 символов, надо увидеть эти 50 символов. Ну и в табличном виде, или в виде какой-то статистики (create statistics).
Если есть возможность увидеть распределение в в виде графика для каждого столбца, было бы вообще отлично.
Извращенный, но действенный вариант:
sys.objects - добываем таблицы, для них - колонки из sys.columns
для всех [n]varchar не максимальной длины - оцениваем заданый размер и факт типа select max(len(нужная колонка)) -> получаем "процент заполнения"
Только зачем это все для var типов?? если бы nchar или char - еще можно было бы понять логику, но для variable length которые от рождения имеют заточку под хранение данных переменной длины.
p/s/ отличия в занимаемом месте между таблицей с полем varchar(5) и с полем varchar(100500) при одинаковых данных длиной 0..1 символ - будут в пределах погрешности
проблемой может быть обратная ситуация - когда таблица имеет поле varchar(100) а по факту туда "нужно уместить" 150 символов
Только зачем это все для var типов?? если бы nchar или char - еще можно было бы понять логику, но для variable length которые от рождения имеют заточку под хранение данных переменной длины.
Насколько помню, mssql хранит большие значения для столбцов (max) отдельно и ссылается на них из строки, это уменьшает производительность. Если у меня нет слишком больших значений, то проще дать этим столбцам переменную длину и пусть хранятся в строке.
Дмитрий Петров, "слишком большие" это 8000/4000 символов и было во времена SQL2000. Сейчас это 2Гб
Единственное что сейчас может быть критичным - 8кб для индекса - то бишь какой-нибудь составной индекс, где фигурирует пара действительно больших полей
Средний
