По умолчанию, в Microsoft Axapta многие коды выровнены "вправо". Пользователи привыкают к этому, но вопросы остаются - зачем и почему сделано так? удобнее и оптимальнее ли такой подход?

 

Зачем включено выравнивание "вправо"?

Сначала разберемся - почему установлено выравнивание вправо. В статье Коды клиентов и поставщиков, я уже писал, что в западных программах принято работать с числовыми кодами. Для западных пользователей числовые коды не выглядят дикими и неудобными.

Западный план счетов

коды клиентов в международной версии

 

Мало того, в западных программах часто используют диапазоны номеров. Например, если для накладных выделяют диапазон с 1 по 999, для счетов-фактур - с 1000 по 1999, а для платежей могут выделить диапазон с 10000 по 99999. Таким образом, западный пользователь по номеру документа может не только идентифицировать документ, но и определить тип этот документа.

В стандартной версии, диапазоны используются и для автоматической нумерации контрагентов - с 3000 по 3999 поставщики, с 4000 до 4999 постоянные клиенты, а с 5000 по 9999 одноразовые поставщики и клиенты.

Заметим, что Axapta хранит коды в строковом поле таблицы. Это делается для того, чтобы можно было использовать не только числовые коды, но и буквенно-числовые. Заметим, что при хранении чисел в строковых полях возникает проблема сортировки.

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

Для того, чтобы сохранить естественный порядок, если используются числовые коды, и сохранить возможность использовать буквенные коды, в Аксапте включен режим выравнивания вправо.

Сортировка чисел Сортировка строк
выравнивание влево
Сортировка строк
выравнивание вправо
1 1 1
2 10 2
3 11 3
4 12 4
5 13 5
6 14 6
7 15 7
8 16 8
9 17 9
10 18 10
11 19 11
12 2 12
13 20 13
14 3 14
15 4 15
16 5 16
17 6 17
18 7 18
19 8 19
20 9 20

 

Нужно ли оставлять выравнивание "вправо"?

На просторах СНГ диапазоны и числовые коды не прижилась. Здесь для определения типа документа обычно используют префиксы. И номера документов выглядят примерно так:

Кстати, в международных демонстрационных данных новой Аксапты тоже используются префиксы и суффиксы.

Поскольку при работе с префиксами используются коды одинаковой ширины, то проблемы сортировки не возникает. В этом случае выравнивание "вправо" не имеет никакого функционального смысла.

 

Плюсы выравнивания "влево"

SQL сервер хранит данные в текстовых полях переменной длины (varchar). Это значит, что правые (trailing) пробелы не хранятся. Это значит, что на диске короткие строки занимают не все максимально возможное для кода место, а значительно меньшее.

Для большинства кодов в Аксапте, по-умолчанию отведено 20 символов. Как правило, реально используемые значения значительно короче.

тип поля с кодом

 

Рассмотрим как хранятся строки выровненные вправо. Хранятся они очень просто - вначале идут пробелы, а в конце значимые символы. Первые пробелы не отбрасываются SQL сервером. Это значит, что все коды занимают максимально возможное место на диске. Причем большую часть занимают незначащие пробелы! Обратите внимание, что коды часто входят в индекс. Индекс по полю выровненному "вправо" также будет занимать максимально возможное место, и обрабатываться этот индекс будет медленнее.

Что произойдет, если включить выравнивание влево? Реально на диске будет хранится меньше данных. SQL-серверу нужно будет считать с диска меньшее число страниц, чтобы получить те же данные. Индексы, в среднем, также будут обрабатываться значительно быстрее. Следовательно значительно возрастает скорость обработки данных.

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

 

Рекомендации

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

Включите выравнивание "влево" для всех нечисловых кодов. Это позволит значительно сократить объем хранимых данных. Только это уже позволит повысить быстродействие обработки данных на SQL сервере.

Кроме того, поскольку коды часто входят в индексы, то уменьшение средней длины индекса за счет отбрасывания незначащих пробелов также положительно скажется на быстродействии системы.

Комментарий: Не забудьте после переключения выравнивания "влево" выполнить реорганизацию данных и переиндексацию на SQL сервере. До реорганизации и переиндексации в страницах базы данных будет много пустот и ощутимого эффекта не заметно.

 

Дополнения

Дополнение от Вадима Гончаренко (04.08.04):

Выравнивание, настраиваемое в форме "Коррекция основных типов" имеет в основном "косметическое" действие и на общий размер БД большого влияния не оказывает.

Зато есть замечательный EDT Num, который в этой форме не редактируется, но у него по умолчанию включено выравнивание вправо. При этом от него наследуется очень много таких расширенных типов данных, как InventTransId, Voucher, InvoiceId, ParmId - весь список можно увидеть, воспользовавшись "Иерархией объектов" в AOD.

Иерархия работает только если построить перекрестные ссылки (примеч. Mazzy)

Т.е. ключевые поля в таких больших таблицах, как InventTransId, InventSettlement, LedgerTrans, значения которых генерятся системой автоматически и никакой смысловой нагрузки не несут (т.е. могут быть достаточно короткими) всегда занимают при хранении 20 байт. Много это или мало - сказать навскидку достаточно сложно, поэтому был проведен следующий эксперимент: на сгенерированной БД (таблица LedgerTrans - порядка 250, InventTrans - 450 тысяч записей) сравнивалось место, занимаемое "тяжелыми" таблицами и их индексами при выравнивании EDT Num "вправо" (по умолчанию) и влево. Для чистоты эксперимента перед измерением проводилась реиндексация с одинаковыми значениями коэффициента заполнения (fillfactor).

Результаты - в таблице:

Выравнивание вправо (по умолчанию)
Таблица Количество записей Выделено Данные Индексы Свободно
INVENTTRANS 445925 459264 309472 149592 200
CUSTINVOICETRANS 266613 276896 214616 62080 200
LEDGERTRANS 277792 186304 88776 97408 120

 

Выравнивание влево
Таблица Количество записей Выделено Данные Индексы Свободно
INVENTTRANS 445925 364120 236824 126952 344
CUSTINVOICETRANS 266613 245360 201960 43256 144
LEDGERTRANS 277792 147792 68456 78968 368

Нюансы: от EDT Num наследуются такие EDT, как, например, SalesId. При выравнивании вправо, если в номерной серии не используется префикс, сортировка в форме заказов будет "правильной":

1
2
3
4
5
6
7
8
9
10
11
12
...

При выравнивании влево в этом случае сортировка "сломается":
1
10
11
12
2
3
4
5
6
7
8
9
...

А при использовании префикса все снова будет в порядке:
ЗК001
ЗК002
ЗК003
ЗК004
ЗК005
ЗК006
ЗК007
ЗК008
ЗК009
ЗК010
ЗК011
ЗК012
...

 

Буду рад Вашим замечаниям и предложениям.
E-Mail: mazzy@mazzy.ru, Мазуркин Сергей