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

[twilight]

Разрабатываю OLAP для DAX 2012.
В тестовой базе около 1 000 000 InventDim.
Для атрибута InventDimId SQL выводит рекомендательное сообщение: Используйте числовые ключевые столбцы для атрибутов, у которых 500 000 и больше членов.

В связи с этим возник такой вопрос: а почему, собственно, в Аксапте используется строковой InventDimId? Все равно Аксапта генерирует его автоматически, обычный пользователь его не видит. Таблица InventDim часто бывает довольно большая. Не лучше ли с точки зрения производительности, если бы InventDimId был бы типа int64?

[ice]

исторически сложилось, на заре почти все идентификаторы были строковые, 64 битов вроде не было

[mazzy]

Цитата:

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

а почему, собственно, в Аксапте используется строковой InventDimId?

Исторически все нумераторы (за очень редким исключением) буквенно-цифровые для того, чтобы:
1. можно было задавать суффиксы-префиксы (для разных целей)
2. можно было использовать более компактную нумерацию (не только цифры, но и буквенный алфавит)

http://axapta.mazzy.ru/lib/numbersequenceformat/

а также
http://axapta.mazzy.ru/lib/numbersequence/

[Ivanhoe]

Следуя логике AX 2012 MS должен был переделать ключ на recid Не успел или не захотел...

[mazzy]

гады они со своим новым подходом

[twilight]

Цитата:

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

Исторически все нумераторы (за очень редким исключением) буквенно-цифровые для того, чтобы:
1. можно было задавать суффиксы-префиксы (для разных целей)
2. можно было использовать более компактную нумерацию (не только цифры, но и буквенный алфавит)

http://axapta.mazzy.ru/lib/numbersequenceformat/

а также
http://axapta.mazzy.ru/lib/numbersequence/

1. Для каких целей можно использовать префиксы / суффиксы в InventDim? Я вижу только вариант, если передавать из одной базы в другую и при этом использовать старый inventDim, но это какой то очень редкий случай и никто не мешает в новой базе сгенерировать новый inventDim по комбинации аналитик.
2. Компактная нумерация это хорошо, если бы InventDimId печатался в документах или выводился на формах, а так с точки зрения БД компактнее как раз число.

[fed]

Цитата:

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

гады они со своим новым подходом

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

[twilight]

Цитата:

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

исторически сложилось, на заре почти все идентификаторы были строковые, 64 битов вроде не было

RecId всегда был и в сопоставлениях прводок по поставщикам / клиентам связь по нему была всегда.

[twilight]

Цитата:

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

Следуя логике AX 2012 MS должен был переделать ключ на recid Не успел или не захотел...

Вот тоже так думаю. InventTrans, например, связывается с InventTransOrigin по RecId.

[ice]

Цитата:

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

RecId всегда был и в сопоставлениях прводок по поставщикам / клиентам связь по нему была всегда.

RecId не был int64. при миграции данных связь по RecId только мешает

[Logger]

Цитата:

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

RecId не был int64. при миграции данных связь по RecId только мешает

А почему мы привязались к recid ?
Можно было просто использовать числовой идентификатор. Номерные серии легко до этого допиливаются, чтобы возвращать целочисленное значение.

Кстати, при одинаковом объеме занимаемого в памяти места, целочисленные ключи, по идее, должны работать в БД быстрее чем строковые. Поэтому InventDimId, InventTransId и.т.п. напрашиваются на то чтобы быть целочисленными (ну или int64)

[mazzy]

Цитата:

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

1. Для каких целей можно использовать префиксы / суффиксы в InventDim? Я вижу только вариант, если передавать из одной базы в другую и при этом использовать старый inventDim, но это какой то очень редкий случай и никто не мешает в новой базе сгенерировать новый inventDim по комбинации аналитик.

думайте дальше.
для того, чтобы отделить inventDim с ячейками и паллетами от обычных,
для того, чтобы отделить inventDim на разных юр.лицах, если юр.лица разделяют общий склад.
да, мало ли для чего?

Цитата:

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

2. Компактная нумерация это хорошо, если бы InventDimId печатался в документах или выводился на формах, а так с точки зрения БД компактнее как раз число.

Не знай... Наработался я с "компактной нумерацией" в Конкорде. Где для разных целей выделялись числовые диапазоны. Ну его нафих. Пусть лучше будет больше возможностей с префиксами и суффиксами. Пусть эти возможности будут даже за счет небольшой потери производительности.

[Vadik]

Цитата:

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

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

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

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

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

[Logger]

Цитата:

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

По мне так большинство выкладок типа "строка быстрее int64" ...

Что правда ?
Я всегда был уверен в обратном. По крайней мере для строк занимающих 8 и более байт.

[Vadik]

Цитата:

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

Что правда ?

Правда. Строка хранимая в юникоде как правило "длиннее" int64, это факт. А вот постулат о том что int64 "быстрее" (и насколько "быстрее") - неплохо было бы доказать

[Logger]

Цитата:

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

Правда. Строка хранимая в юникоде как правило "длиннее" int64, это факт. А вот постулат о том что int64 "быстрее" (и насколько "быстрее") - неплохо было бы доказать

Попробую сделать сделать пример как дойдут руки.
Мнение свое сложил на основе обсуждений на SQL.ru - там были темы, где народ обсуждал оптимальную схему БД для биллинга. Однозначно высказывались в пользу целочисленных идентификаторов по сравнению со строковыми. Основной аргумент - на больших объемах (а в биллинге они большие) сравнение по числам (как следствие, поиск и.т.п.) должно идти значительно быстрее.

[Vadik]

Цитата:

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

Попробую сделать сделать пример как дойдут руки

Буду премного благодарен. В качестве затравки - у меня в INVENTDIM 4518730 записей, singleton_lookup-ы по INVENTDIMID составляют 99.997% ко всем чтениям (статистика снята с продуктива). Вот давайте эти singleton_lookup-ы и попробуем "разогнать" сменой связи c INVENTDIMID на RECID

[twilight]

Цитата:

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

для того, чтобы отделить inventDim с ячейками и паллетами от обычных,

А что это дает?

Цитата:

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

для того, чтобы отделить inventDim на разных юр.лицах, если юр.лица разделяют общий склад.

А чем не нравится аналитика Владелец?

Цитата:

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

да, мало ли для чего?

На проектах, которые я видел, InventDimId использовался только по прямому назначению и никак не модифицировался, потому и спрашиваю.

[handy-comp]

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

С другой стороны вопрос насколько выгодней и какого эффекта мы хотим достичь. Потому как на чтение данных эти изменения повлияют в меньшей степени, да и будет ли вообще заметен эффект на объемах типа 4,5 млн записей ...

[Vadik]

Цитата:

Сообщение от handy-comp

Т.е. для вставки и обновления данных конечно выгодней было бы иметь InventDimId типа Int64

Интенсивная вставка ? Обновления ? Мы все еще индекс на InventDim по InventDimId обсуждаем ? Напомню, основной способ доступа - singleton_lookup

Цитата:

Тут думаю уместно будет вспомнить, что в InventDim построен кластерный индекс по InventDimId.
В таком случае, использование всяких префиксов и суффиксов в ключевом поле удорожает процесс вставки данных, т.к. приводит к фрагментации

А можно "на пальцах" показать как префиксы в номерной серии приводят к усиленной фрагментации при вставке ? А то мне как-то казалось что при выделении в рамках одной сессии значение номерной серии монотонно возрастает, а в случае множественных сессий и неиспользования предварительного выделения номеров из серии фрагментация даже меньше чем при индексе по RecId и множественных инстансах AOS