Правильные справочники

[belugin]

Кстати, ограничение в 7 таблиц - аксаптовское или откуда (хотя, наверное, для SQL server это маловато)?

[MikeR]

Понятие 7 как магического числа таблиц для формы было введено wamr. Ссылку найти не смог.
Ключ символьного типа юзается в аксапте из за номерных серий на мой взгляд. Хотя использование integer увеличило бы performance select-а. Например в 1С так и происходит.

[belugin]

Есть ли количественные оценки выгоды от перехода str --> int?

[glibs]

В плане места было тут (там укорачивался символьный код в ключевых полях, но эффект будет такой же)

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

В плане производительности не припоминаю. Но можно поставить какой-нибудь эксперимент. Я не сомневаюсь в преимуществах коротких кодов в целом (даже эксперимент ставить лень).

[mazzy]

Цитата:

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

Есть устойчивая концептуальная проблема со справочниками.

Почему проблема?

Цитата:

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

Она исходит из двух посылок:
1. Аксапта практически не использует суррогатных ключей.

Да, и слава богу.

Цитата:

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

2. Аксапта не поддерживает вывод наименования рядом с кодом в ссылке на справоч8ник

Тогда уж дописывай: не занимается выводом наименования автоматически.
И слава богу, что не занимается.
Потому что простой select по одной таблице автоматически превратился в грандиозный запрос с кучей join'ов.
Кроме того, в Аксапте есть наименования на разных языках...

Ты видимо с 1Сv8 не работал и не видел ошибку "в запросе не может быть более 256 таблиц...". В последних релизах патч сделали - собирают несколько разных запросов.

И добавлю еще: там где это действительно нужно, Аксапта нисколько не мешает программисту добавить свои join'ы, чтобы показать наименование.

Цитата:

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

Во-вторых, для вывода описаний значений справочника надо делать дополнительный код (обычно, дисплей-методы)

Ай-ай-ай... Ну, не создает эта собака дополнительные запросы.
Оставляет на откуп программисту. Вот ведь сволочь то какая...

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

Цитата:

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

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

Ай-ай-ай... А в запросе CTRL+F3 добавить таблицу руками и записать запрос никак?
Блин, ей богу не ожидал.

Ну, не делает она сама запросы. Не нагружает она сервер.
И слава богу.

Цитата:

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

Кто как решает эту проблему?

Ни в коем случае не программировать как говорят некоторые.
Или программировать в крайнем случае, когда клиент уж совсем уперся. Но четко осозновая, что для каждого наименования получится дополнительный join. Со всеми вытекающими последствиями для производительности.

Цитата:

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

Я встречал два противоположных способа и их горячих сторонников.

1. Идентификаторы делают длинными и осмысленными -- соотвественно они требуют переименования при изменении названия значения

2. Идентификаторы делают неосмысленными или они содержат небольшой условный префикс и номер типа спирт001.

см. http://axapta.mazzy.ru/lib/autonumber/
а также http://forum.mazzy.ru/index.php?showtopic=82

Цитата:

Какой по вашему должны быть структура справочника?

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

ты наверное спрашивал про структуру кода.

Цитата:

Есть ли у вас проблема того,что пользователи требуют фильтрацию по наименованию прямо в гриде?

Почему ты считаешь это проблемой?

Цитата:

Сообщение от Владимир Максимов

С чисто формальной стороны, то, что используется в AXAPTA и есть суррогатный ключ, поскольку это не есть информационное поле.

Почему это "суррогатный" и почему не информационное?

Цитата:

Сообщение от Владимир Максимов

А в AXAPTA пошли более простым путем - дали пользователю возможность напрямую как просматривать, так и вводить коды записей.

А также дали возможность и не вводить, если вы укажете нумератор.

Цитата:

Сообщение от Владимир Максимов

Поэтому возникла иллюзия того, что это "естесственные ключи". На самом деле это не так.

Почему?

Цитата:

Сообщение от Владимир Максимов

Где-то здесь была ссылка на статью Mazzy по поводу поиска по внешнему ключу в связанном справочнике. Не могу найти.

Привел чут выше.
Также сделайте поиск по слову суррогатный и естественный.

Цитата:

Сообщение от Владимир Максимов

Суть в том, что таблица-справочник цепляется по JOIN к основной таблице и в Grid отображаются напрямую поля из таблицы-справочника. Никаких дисплейных методов и дополнительных полей.

Работают все штатные механизмы поиска и фильтрации. Более того, через расширенное окно поиска можно задать критерии отбора по полям, не отображаемым на форме.

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

Цитата:

Сообщение от Владимир Максимов

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

И это тоже

Цитата:

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

Мне нравится понятие искусственный ключ.

Почему?

См. также: http://sql.ru/forum/actualthread.aspx?tid=104535

И еще:
Нумератор строковый, а не числовой, чтобы можно было делать суффиксы-префиксы.
Числовой был раньше. Еще в конкорде.
Там приходилось выделять диапазоны чисел. Например, с 1000 по 3999 идут клиенты, а с 4000 по 6999 - поставщики.
В Аксапте 2.1 пошли на компромисс и снижение производительности ради наглядности кода. (но ради совместимости с Конкордом сохранили выравнивание вправо)
В Аксапте 4.0 наконец-то отказались от выравнивания вправо (по умолчани все коды выравняны влево)

[gl00mie]

Цитата:

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

Кстати, ограничение в 7 таблиц - аксаптовское или откуда?

Здрассти... известный глюк парсера запросов в трешке. Уже и официально в MBS в 2005-м году писали об этом, и с порядком соединения datasource'ов люди шаманили, и выяснили, что вроде как глюки начинаются только со "2-го уровня" join, и даже что там, где на Ms SQL вылезает данный глюк, при использовании Oracle может быть все ok.

[MikeR]

Цитата:

Есть ли количественные оценки выгоды от перехода str --> int?

на больших таблицах выигрыш будет ощутимым.

[belugin]

Термины.

Искусственный ключ -- сгенерированный ключ, который используется пользователем и внутри базы данных (например, EmplID)

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

Точки зрения сторонников EK и СК изложены тут:
СК: Natural Keys Versus Artificial Keys by Tentser (Russian)

ЕК: Ключ или отмычка

Цитата:

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

занимается выводом наименования автоматически.
И слава богу, что не занимается.
Потому что простой select по одной таблице автоматически превратился в грандиозный запрос с кучей join'ов.

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

Цитата:

Ты видимо с 1Сv8 не работал и не видел ошибку "в запросе не может быть более 256 таблиц...". В последних релизах патч сделали - собирают несколько разных запросов.

Это уже вопрос механизма. Можно, например, реализовать дисплей методами вывод наименований а при фильтрации по ним джоинить или подзапросить.

Еще мне очень нравится понятие graceful degradation -- делаем что можем, если что-то не можем, то делаем только это.

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

Цитата:

И добавлю еще: там где это действительно нужно, Аксапта нисколько не мешает программисту добавить свои join'ы, чтобы показать наименование.

1. Она мешает ограничением на 7 джоинов
2. Она не дает фильтровать по аутерджоинам

Цитата:

Ай-ай-ай... Ну, не создает эта собака дополнительные запросы.
Оставляет на откуп программисту. Вот ведь сволочь то какая...

я предлагаю опционально. По факту многие (и я сам в том числе) пишут вот такие дисплей методы:

display InventName inventName()
{
      return InventTable::find(this.ItemID).Name;
}

здесь собака аксапта выбирает все поля а не только Name. Так что вредные автоматизмы по факту присутствуют все равно.

Цитата:

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

Повторюсь:
1. Опционально
2. Не обязательно джоинить

Цитата:

Ай-ай-ай... А в запросе CTRL+F3 добавить таблицу руками и записать запрос никак?
Блин, ей богу не ожидал.

А было бы плохо, если бы то же самое можно было бы сделать более удобно?

Цитата:

Ни в коем случае не программировать как говорят некоторые.
Или программировать в крайнем случае, когда клиент уж совсем уперся. Но четко осозновая, что для каждого наименования получится дополнительный join. Со всеми вытекающими последствиями для производительности.

Спасибо за ответ и за ссылки.

Вопрос про ЕК такой: что вы делаете когда он меняется? Например был клиент "Светик" а стал "Мотылек"? Или изменилось структура групп номенклатуры вместо

ПЛ0001 (Группа "плюшевые игрушки", изделие 0001 "Медвежонок "Миша"")
МЛ0001 (Группа "плюшевые игрушки для младшего возраста", , изделие 0001 "Медвежонок "Миша"")

переименовываете первичный ключ, даже если он участвует в InventTrans и иногда его надо сопоставлять с распечатанными год назад документами?

[mazzy]

Цитата:

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

Искусственный ключ -- сгенерированный ключ, который используется пользователем и внутри базы данных (например, EmplID)

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

Точки зрения сторонников EK и СК изложены тут:

ЕК - естественный ключ?
А каково твое определение для ЕК?

Цитата:

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

Я предлагаю, чтобы автоматизм был опциональным.

А... с этим согласен.

Цитата:

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

Еще мне очень нравится понятие graceful degradation -- делаем что можем, если что-то не можем, то делаем только это.

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

А реально, что мы можем с этим сделать?
Написать скрипты редактора по созданию таких методов?

Цитата:

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

display InventName inventName()
{
      return InventTable::find(this.ItemID).Name;
}

здесь собака аксапта выбирает все поля а не только Name. Так что вредные автоматизмы по факту присутствуют все равно.

чтобы "собака аксапта выбирала не все поля, а только Name" надо не find вызывать, а делать select по одному полю.

Не, этот пример не катит.
Если уж я чего-то пишу в коде, то не стоит сваливать на аксапту, по-моему
А вот если я не пишу, а работаю только свойствами и объектами AOT...

Цитата:

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

А было бы плохо, если бы то же самое можно было бы сделать более удобно?

Как именно? Показывать наименование?
Нужно показывать одно поле Name? Вместе с полем NameAlias? Вместе с полем, которое показывает Название на текущем/другом языке?

Цитата:

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

Вопрос про ЕК такой: что вы делаете когда он меняется? Например был клиент "Светик" а стал "Мотылек"? Или изменилось структура групп номенклатуры вместо
...
переименовываете первичный ключ, даже если он участвует в InventTrans и иногда его надо сопоставлять с распечатанными год назад документами?

Если сохранять историю не обязательно (как с группами номенклатуры), то переименование.
Если сохранять историю обязательно, то создается новая запись, а старая блокируется от использования.

[belugin]

Цитата:

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

ЕК - естественный ключ?
А каково твое определение для ЕК?

ЕК ключ который генерируется вне системы => вне нашего контроля (типа наименование, или ИНН или что-то еще). Т.е. имеет бизнес-значение.

Цитата:

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

Я предлагаю по-крайней мере, донести до них эту информацию.

Цитата:

А реально, что мы можем с этим сделать?
Написать скрипты редактора по созданию таких методов?

Ну необязательно редактора можно по типу существующего для find&exist

Цитата:

чтобы "собака аксапта выбирала не все поля, а только Name" надо не find вызывать, а делать select по одному полю.

К сожалению, среда делает удобным писать именно find.

Цитата:

Не, этот пример не катит.
Если уж я чего-то пишу в коде, то не стоит сваливать на аксапту, по-моему
А вот если я не пишу, а работаю только свойствами и объектами AOT...

Мне кажется все равно - надо понимать что делаешь. Но лучше будет среда, которая будет облегчать распространенные вещи делать эффективно.

Цитата:

Как именно? Показывать наименование?
Нужно показывать одно поле Name? Вместе с полем NameAlias? Вместе с полем, которое показывает Название на текущем/другом языке?

Я уже предложил см. Правильные справочники

Цитата:

Если сохранять историю не обязательно (как с группами номенклатуры), то переименование.

Даже если на него ссылается миллион записей?

[gl00mie]

Цитата:

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

Вопрос про ЕК такой: что вы делаете когда он меняется? Например был клиент "Светик" а стал "Мотылек"? Или изменилось структура групп номенклатуры вместо
ПЛ0001 (Группа "плюшевые игрушки", изделие 0001 "Медвежонок "Миша"")
МЛ0001 (Группа "плюшевые игрушки для младшего возраста", , изделие 0001 "Медвежонок "Миша"")
переименовываете первичный ключ, даже если он участвует в InventTrans и иногда его надо сопоставлять с распечатанными год назад документами?

Была схожая задача, связанная с миграцией данных по номенклатуре из 1С и необходимостью поддерживать связь с 1С по кодам номенклатуры для выгрузки данных в бухгалтерию. В 1С у номенклатуры был код из одних цифр (от 00001 до 20000, к примеру) и название, в котором было по историческим причинам «зашифровано» 4-5 нечетко формализованных группировочных признаков номенклатуры. Причем алгоритм составления таких названий - не просто конкатенация: в зависимости от значений одних группировочных признаков другие могли не попадать в название или кодироваться иначе. На это все накладывалась еще одна особенность, связанная с тем, что для одной номенклатуры необходимо поддерживать три различных названия: бухгалтерское, управленческое для AX, схожее с тем, что пишут поставщики в своих документах, и управленческое для 1С, к которому привыкли все кладовщики и другого понимать они не хотят. Причем алгоритм формирования управленческих названий разный для каждого из нескольких направлений деятельности и связанной с ними номенклатуры (хотя группировочные признаки одни и те же). Так вот, решение было выбрано такое:

• для номенклатур используются те же цифровые ничего не значащие коды, что и в 1С, и эти коды никодга не меняются для номенклатуры. В любом случае, коды ПЛ0001 или МЛ0001 imho ничуть не лучше просто 00001, который не обязан меняться вместе со структурой групп;
• отказались от иерархического справочника номенклатуры в пользу плоской таблицы с фильтрами и сортировкой по любому группировочному признаку;
• реализованы методы на InventTable, которые умееют генерить все нужные названия по разным алгоритмам в зависимости от значений группировочных признаков номенклатуры (на каждый группировочный признак есть отдельная таблица с несколькими полями, участвующими в формировании различных названий);
• сгенеренные названия сохраняются в InventTxt, причем бухгалтерское - с кодом текущего используемого языка (русского), а управленческие - с дополнительно заведенными в LanguageTable кодами userDefined-"языков" по одному на каждый вид управленческих названий;
• в ряд форм, таких как PurchQuickQuote/SalesQuickQuote, для поиска и фильтрации были выведены эти группировочные признаки номенклатуры, в другие формы просто через display-методы выведены соответствующие управленческие названия.

Цитата:

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

По факту многие (и я сам в том числе) пишут вот такие дисплей методы:

display InventName inventName()
{
      return InventTable::find(this.ItemID).Name;
}

Был создан вспомогательный класс, который, во-первых, отвечает за обновление названий (дергается из InventTable при изменении кодов группировочных признаков и из таблиц самих признаков при изменении записей в них), а во-вторых, вызываясь из display-методов на нужных таблицах (SalesLine/PurchLine, к примеру), по itemId и languageId возвращает нужное управленческое название из InventTxt, что работает довольно быстро с учетом настроек кэширования для этой таблицы.
Да, еще приходилось в заголовках форм выводить управленческие названия вместо TitleField2...

[fed]

Цитата:

Есть ли количественные оценки выгоды от перехода str --> int?

Насколько я понимаю, и в MS SQL и в Oracle, числовые поля с фиксированной точностью (numeric aka decimals) храняться как Binary Coded Decimal (То есть - каждый десятичный разряд занимает полбайта). Время поиска по уникальному ключу грубо приблизительно равняется логарифму числа записей по основанию числа ключей в странице. Соответствнно - чтобы посчитать выигрыш надо посчитать соотношение логарифмов по основанию n и n*2. Как-то я правила алгебры уже подзабыл порядком - попробуйте сами подсчитать в общем случае
Ну и по хорошему - надо еще помнить о том что в странице на каждый ключ еще добавляется 6-8 байтов служебной информации со ссылками. Поэтому - если ключи и так были короткие, то особого прорыва не случиться.

[mazzy]

Цитата:

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

ЕК ключ который генерируется вне системы => вне нашего контроля (типа наименование, или ИНН или что-то еще). Т.е. имеет бизнес-значение.

Э-э-э... А если внутри, то бизнес-значения не имеет?

Цитата:

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

Я предлагаю по-крайней мере, донести до них эту информацию.

А... да, почему бы не сделать это?

Цитата:

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

Мне кажется все равно - надо понимать что делаешь. Но лучше будет среда, которая будет облегчать распространенные вещи делать эффективно.

Что такое "распространненные вещи"?
И где они распространены?
Здесь я пытался понять почему же проклятые буржуи используют код, а не наименование.
http://axapta.mazzy.ru/lib/autonumber/

А ведь действительно, клиенты-поставщики у них просто нумеруются.
Причем не только в Аксапте/Навижине. Погляди на интернет магазины, посмотри на другие системы (кстати, а как это делается в BAAN?)

Цитата:

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

Я уже предложил см. Правильные справочники

Может быть, может быть...

Цитата:

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

Даже если на него ссылается миллион записей?

Да. Это разовая процедура. Требуется раз в полстолетия.
А ты предлагаешь делать join каждый раз?

Цитата:

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

Причем алгоритм составления таких названий - не просто конкатенация: в зависимости от значений одних группировочных признаков другие могли не попадать в название или кодироваться иначе.

Составной код - еще больший отстой нежели никому не понятное число.
Поскольку: нарушается нормализация первой формы.

Цитата:

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

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

ВО!
Максим, будешь создавать 3 EDT или просить добавить в EDT массив наименований?

Цитата:

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

отказались от иерархического справочника номенклатуры в пользу плоской таблицы с фильтрами и сортировкой по любому группировочному признаку;

ВАХ! Целиком и полностью поддерживаю!
http://axapta.mazzy.ru/lib/tree/
http://axapta.mazzy.ru/lib/tree2/
http://axapta.mazzy.ru/lib/tree3/
а также: http://forum.mazzy.ru/index.php?showtopic=1275

Цитата:

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

в ряд форм, таких как PurchQuickQuote/SalesQuickQuote, для поиска и фильтрации были выведены эти группировочные признаки номенклатуры, в другие формы просто через display-методы выведены соответствующие управленческие названия.

Целиком и полностью поддерживаю
Особенно согласен с формулировкой "ряд форм".
Немножко смущает, что нет формулировки "ряд отчетов".

[mazzy]

Цитата:

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

Я уже предложил см. Правильные справочники

И еще. Не забывай об OLAP, reporting service, performance point'ах и прочих экселях.

[gl00mie]

Цитата:

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

Составной код - еще больший отстой нежели никому не понятное число. Поскольку: нарушается нормализация первой формы.

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

Цитата:

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

http://axapta.mazzy.ru/lib/tree/
http://axapta.mazzy.ru/lib/tree2/
http://axapta.mazzy.ru/lib/tree3/
а также: http://forum.mazzy.ru/index.php?showtopic=1275

да, собственно, эти статьи и послужили аргументом для пользователей, ничего кроме иерархических справочников 1С доселе не видевших

Цитата:

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

Немножко смущает, что нет формулировки "ряд отчетов".

Ну это как бы подразумевалось просто здесь разговор в основном именно о формах, как я понимаю.

[belugin]

Цитата:

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

Погляди на интернет магазины, посмотри на другие системы (кстати, а как это делается в BAAN?)

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

[belugin]

Цитата:

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

Э-э-э... А если внутри, то бизнес-значения не имеет?

Ну ИК может иметь, а СК - нет.

Цитата:

Что такое "распространненные вещи"?
И где они распространены?
Здесь я пытался понять почему же проклятые буржуи используют код, а не наименование.

Лично в моей практике часто приходится делать наименования. Мне например, трудно представить, чтобы кого-то удовлетворил EmplID

Цитата:

А ты предлагаешь делать join каждый раз?

Про джоин я уже ответил, что он необязательный.

Цитата:

Максим, будешь создавать 3 EDT или просить добавить в EDT массив наименований?

Ну... всегоя можно найти особый случай

[oip]

Цитата:

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

Мне например, трудно представить, чтобы кого-то удовлетворил EmplID

У нас всех удовлетворяет, ибо ЕмплАйди у нас вида "АбрамоваСМ".

Вот с номенклатурами - да, беда.

[belugin]

Цитата:

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

У нас всех удовлетворяет, ибо ЕмплАйди у нас вида "АбрамоваСМ".

А если она замуж выйдет?

[mazzy]

Цитата:

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

Лично в моей практике часто приходится делать наименования. Мне например, трудно представить, чтобы кого-то удовлетворил EmplID

Кого-то не устраивает табельный номер?

Про Абрамову уже говорили.
Если она замуж выйдет, то стандартная процедура RenamePrimaryKey для изменения КОДА