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

Сломал голову. Решить не в состоянии, так как теорию вопроса уже забыл (да еще и не знал). Помогите!

Имеется некий набор значений, (n, m, k), который нужно отобразить на ряд целых чисел.
Набор значений k - может меняться, он монотонно растет (очень медленно)
Набор значений n, m - всегда неизменен.


Необходимо нарисовать некую функцию x=F(n, m, k), набор х значений которой удовлетворял бы следующим свойствам:
1. Каждому значению (n, m, k) должно соответствовать одно и только одно значение х, и каждому значению х должно соответствовать одно и только одно значение (n, m, k).
2. Набор значений х должен хорошо ложиться в правила формирования статистик mssqlserver, причем преимущественно адекватно должно оцениваться количество наборов с одинаковым k.
Т.е. наборы значений с одинаковым k должны ложиться примерно в один персентиль значений x, с т.з. формирования статистик mssqlserver.
3. Значения x, соответствующие одному k - должны быть интервальными, и не пересекающимися с другими значениями х наборов с другим k.
Т.е. всему множеству (n, m, 60) должен соответствовать некий интервал значений х, например 1...1000, причем никакому другому значению k тот же интервал соответствовать не должен. Т.е. ситуация, когда k = 60 соответствуют значения 1, 3, 5... а k=59 - 2, 4, 6 - недопустима.
4. Набор значений х должен быть максимально компактным. Вместе с тем условия непрерывности на ряд значений х - не накладывается. Т.е., совершенно необязательно, чтобы значения х шли без разрывов и max(x) - min(x) = 5124.
Требуется лишь чтобы по этому набору хорошо строилась статистика, см. п.2.
5. Предположим, у нас есть таблица n, m, k, x рассчитанная.
Значений:
0, 0, 60, х1 - 100
0, 1, 60, х2 - 1 млн.
1, 0, 60, х3 - 1
2, 0, 60, х4 - 10 тыс.
Оптимизатор, при запросе select * from tbl where x = x4 - должен или адекватно оценивать количество строк (10 тыс.), либо полагать их ~ 1 млн.

Возможно, я задаю чересчур жесткие условия, но пока не получается сформулировать с меньшим количеством ограничений...

aleks222, Неа, не подходит.
Оно не дает int на выходе.
... а хотелось бы вообще smallint, но это мечты.
И гистограмма будет дырявая.

Фактически, переделы как раз и озвучены. Количество k может увеличиться на ~10 за несколько лет, количество значений n - на пару-тройку за несколько лет (но можно считать статическим).

Указанный алгоритм не подходит, интервалы получаются не-непрерывные по k, см. п.3.

К сожалению, студентом я был 30 лет назад :-(
В bit - хотелось бы, но, к сожалению 5 тыс. значений в трех измерениях в него не поместятся.

Размер имеет значение.

Подоплека задачи:

Имеется таблица, примерно на миллиард записей.
Каждую запись можно охарактеризовать группой из 3 признаков, в итоге - см. выше.
Хочется сопоставить этим признакам некое число, и использовать его:
1. Как ключ при разбиении на секции
2. Как хеширующий признак при выборках. Именно поэтому важна интервальность, прежде всего - по k, но желательно еще и по n

Сейчас ключ строится как: k*10000 + n * 1000 + m
Но у него совершенно жуткая статистика!
Размах значений в 60 тыс, причем значения разбросаны очень неравномерно.
В результате MSSQLSERVER строит совершенно жуткую гистограмму по этому полю.
Как результат оптимизатор периодически или ударяется в сканирование всего, или рисует нестед лупы, полагая, что для какого-то значения мало записей.
А количество записей с каждым признаком - действительно неравномерное. От 0 до 20-30 млн.
Собственно, поэтому и задача.

Плохая идея. k и n - могут измениться. При этом все признаки пересчитывать?
Т.е. последовательность целых чисел - неустойчиво к изменению количества признаков.

Кроме того - проблемы со статистикой оно никак не решает.
Нужно, чтобы статистика MSSQLSERVER адекватно оценивало количество значений, которое хотя бы соответствует одному k
Т.е., фиг с ним, пусть промахивается при оценке количества для конкретного значения ( k, n, m ). Но пусть оценивает его хотя бы соответствующим количеству значений с определенным k.

А непромокаемый порох давно изобретен.
В виде унитарного патрона :-)

felix_ff, да, но оно получается слишком грубым приближением.
Я не совсем правильно выразился.
Правильнее так:
Хочется, чтобы оптимизатор правильно оценивал статистику по (k, n, m).
Но уж если по какому то набору это не получается - пусть промахивается, и считает как по диапазону одного значения k, или его подмножеству.
Я понимаю, что 5000 значений в 200 интервалов не уместить, но хоть что-то в этом направлении сделать.

Кроме того ладно, пусть будет "как по k", только поле нужно всё равно кодирующее все 3 признака, и взаимооднозначно.

mayton, Ненене! Избыточно.
Возможные значения, собственно, перечислены в исходном запросе.
n - максимум 10, сейчас 5, и рост до 10 - в неопределенной перспективе, можно этим пренебречь.
k - 60, максимум - 100 значений.
m - в точности 12 (точнее, 11 и "прочее", так что 12).
Итого в ключе менее 10 тыс. вариантов.
И всё это нормально влазит в smallint. Проблема то как раз в том, чтобы сконструировать это значение таким образом, чтобы по нему нормально создавалась статистика.

felix_ff,
вам было предложено в виде "хеш-функции" взять бинарное представление, статистика по столбцу binary тоже строится нормально.

На маленьких примерах - всё замечательно работает.
Теперь представьте, что ключей ~ 5000, а количество входов по каждому ключу - от 1 (единицы) до 20 млн.
В среднем - порядка миллиона, но очень неровно.

В том то и дело что ничего.
Если ТС хочет добиться поведения при котором оптимизатор посмотрев объект статистики по любому ключу будет ему выдавать оценку как если бы бы этот самый ключ представлял RANGE_HIGH_KEY значение - то хер.

Лимит шагов в гистограмме 200. точное число строк выдается в виде EQ_ROWS если запрашивается ключ попадающий в RHK.
в случаях если в интервале лежат несколько ключей в расчет будет идти значение AVG_RANGE_ROWS, при этом если в интервале наблюдается сильная дисперсия значений то увы здесь ничего не поделаешь.
здесь только создавать фильтрованные статистики для большей детализации, но автоматом сиквел такую ситуацию не разрулит.
Ага, примерно этого и хочу, и понимаю, что это - невозможно.
Я понимаю, что 5000 уникальных ключей на 200 интервалов - не отобразишь.
И фильтрованная статистика - не годиться, т.к. она не бывает инкрементальной, а нужна именно инкрементальная.

Я хочу таким образом подобрать значения ключей, чтобы:
1) 1 ключу соответствовал один и только один набор этих трех параметров (n, m, k)
2) При построении статистики по записям с такими ключами статистика вела бы себя, в худшем случае, как построенная по полю k (60 уникальных входов, и в 200 шаговую диаграмму - замечательно укладывается целиком), но, возможно с несколько большей детализацией (т.к. значений k - 60, а шагов в гистограмме - в 3,5 раза больше).
3) При этом чтобы значение ключа было целым числом, а лучше smallint, ибо дорого.
И 4) Можно было достоверно сказать, что диапазон ключа between x1 and x2 - относится к одному и только одному значению k.

А именно так и сделано уже .
Просто ключ выбран, как мне видится - очень неудачно.
Сейчас он считается как: k*10000 + n * 1000 + m
И это приводит к тому, что набор значений ключа очень "полосатый". Разброс между минимальным значением и максимальным - 600 тыс., и значения ключа, которые соответствуют реальным координатам (n,m,k) - очень "островковые".
Это приводит к тому, что mssqlserver не может построить по нему адекватную гистограмму. Например, выпадают и неверно оцениваются промежутки, соответствующие некоторым k, и он начинает оценивать количество значений, как количество между неким k-3 и k+5 (например), что совсем не в ту степь, т.к., напоминаю, речь идет о миллионах записей.
Поэтому и хочется как то изменить алгоритм построения ключа, чтобы он стал статистически более равномерным, и гистограмма по нему выглядела, ну, как построенная по k в первом приближении. Или чуть более детально, чем по k (в k, напоминаю, 60 уникальных значений, и возможен рост до 100, но не более и не мгновенно, когда-нибудь, короче).

felix_ff статистика должна быть инкрементальной, т.к. таблица пополняется подменой секций. Если на таблице имеется не-инкрементальная статистика - выполнить switch partition не получится.

Я вот думаю, может ключ сделать char(4) и кодировать его значения в 16 или, скажем, 32-ричной системе?