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

[mazzy]

Цитата:

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

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

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

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

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

[twilight]

Цитата:

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

[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

[Logger]

Цитата:

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

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

Интересно, почему так получилось ? Неужели настолько часто дергается find(). Мне казалось что Invnetdim очень часто в джоинах бывает. Или они тоже могут приводить к такому способу доступа ?

[handy-comp]

Цитата:

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

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

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

Цитата:

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

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

Вот тут хорошо описано про кластерные индексы http://www.somewheresomehow.ru/clust...key-selection/
На пальцах, записи физически отсортированы по кластерному индексу, если мы вставляем запись то с одним префиксом ключа то с другим (как здесь предлагалось для визуального разделения) системе приходится резервировать пустые места для вставки данных в разные места таблицы.