Производительность и ключ InventDim

[Vadik]

Цитата:

Сообщение от fed

Ну так сначала они насильственно переделали все строки на UNICODE, в результате чего размер ключа увеличился в два раза. Потом они начали георически бороться с последствиями. Причем смысл перехода на unicode не очень понятен. Если у нас в БД стоит немецкая кодовая таблица, то даже если кодировка поддерживает кирилицу и китайские ироглифы, все равно вся сортировка в системе будет немецкой, а не русской или китайской. То есть - столько гемора, а по большому счету - 50% проблем интернационализации не решено...

Вот далась тебе эта сортировка - раньше хранить нормально вместе немецкий и китайский нельзя было. Вообще. А теперь можно и это хорошо. Потом, что есть "правильная" сортировка для данных хранящихся вперемешку на английском, русском, мандаринском, французском и немецком ? Нет ее. Или есть, но разная с точки зрения китайца и француза, так что - в морг. Да, есть накладные расходы в виде "распухающих" из-за UNICODE ключевых полей, с этим в том числе борются введением суррогатных ключей.

По мне так большинство выкладок типа "строка быстрее int64" - скорее из области перфекционизма, но учитывая как в MS любят "наворачивать" архитектуру - будьте уверены, переведут и INVENTDIM на связи по RECID, ничтоже сумняшеся. А потом то же сделают с DATAAREAID (по аналигии с PARTITIONID). А потом - нормализуют связку {DATAAREAID;PARTITIONID} вынеся ее во внешнюю таблицу и ссылаясь на нее по RECID.. А потом.. Перфекционизм, итить его

Хотя, может они и правы - время покажет