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

[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? Вместе с полем, которое показывает Название на текущем/другом языке?

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

Цитата:

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

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

[mazzy]

Цитата:

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

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

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

[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...

[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-методы выведены соответствующие управленческие названия.

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

[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 для изменения КОДА

[belugin]

Цитата:

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

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

Ну, обычно люди еще хотят ФИО рядом видеть...

Вообще, получается, что я один такой несчастный, что все от меня наименования требуют. Остальных удовлетворяет значимый ID и только он и дисплей методов типа

display EmplName emplName()
{
     return (select firstOnly EmplName from EmplTable 
             where EmplTable.EmplID == this.EmplID).EmplName;
}

никто не пишет?

[mazzy]

Цитата:

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

Вообще, получается, что я один такой несчастный

Почему ты так решил?
Это постоянная тема.
См. например ссылку на обсуждение Абстрактного классификатора и поищи обсуждения по ключевому слову лукап/lookup


Анекдот:
Жена (Ж) звонит на мобильный мужу (М).
(Ж) - дорогой, будь осторожен, по радио сообщили, что какой-то идиот едет по встречной полосе
(М) - да их тут сотни!

[Zepp]

Цитата:

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

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

К сожалению изменить EmplId через "Паспорт записи" недостаточно (AX 3.0 SP4 EE). При создании строки в EmplTable создается строка в таблице RHRMVirtualNetworkTable, при этом ключевому полю hrmVirtualNetworkId присваивается значение поля EmplId. При изменении кода в EmplId, код в hrmVirtualNetworkId останется прежним - в результате нельзя будет создать нового сотрудника в EmplTable с прежним кодом.