Теоретический вопрос. Варианты связи таблиц.

[ta_and]

Здравствуйте.

Возник чисто теоретический вопрос.
Почему в Ах повсеместно используется вариант определения связи нескольких таблиц с помощью двух полей: 1. Тип связи 2. Значение определяющее связь.
Например:
В первом поле задается перечисление:
Нет связи
По группе
По номенклатуре
Во втором поле должно храниться либо пустое значение либо значение кода группы, либо номенклатура.
Вопрос.
Почему нельзя использовать альтернативный способ связи нескольких таблиц по типу
два поля 1. Ссылка на группу 2. Ссылка на номенклатуру?

Если задано значение в первом поле - делается ссылка на группу. Если задано значение во втором поле - ссылка на номенклатуру. Если оба пустые - ссылок нет.
--------------
Плюсы первого подхода:
1. Меньше места для хранения значений. (вместо строкового значения в первом поле будет храниться байт перечисления. Ну да. очень большая экономия)

Плюсы второго подхода:
1. Четкая связь таблиц по одному полю.

....
Какие будут мысли у сообщества?

[trud]

Цитата:

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

Если задано значение в первом поле - делается ссылка на группу. Если задано значение во втором поле - ссылка на номенклатуру. Если оба пустые - ссылок нет.

А если значение задано в обоих и номенклатура не принадлежит указанной группе?

[TasmanianDevil]

Цитата:

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

А если значение задано в обоих и номенклатура не принадлежит указанной группе?

Не мешайте людям устраивать забеги по граблям.

Ничто так не приближает к просветлению, как шишки на собственном лбу и работа по исправлению последствий собственных неоднозначных решений

[Ivanhoe]

Цитата:

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

А если значение задано в обоих и номенклатура не принадлежит указанной группе?

Те же вопросы к стандартному подходу.

[Ivanhoe]

Цитата:

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

Не мешайте людям устраивать забеги по граблям.

Ничто так не приближает к просветлению, как шишки на собственном лбу и работа по исправлению последствий собственных неоднозначных решений

Конструктивно. А по делу?

[trud]

Цитата:

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

Те же вопросы к стандартному подходу.

Ну в стандарте если валидация прошла такой проблемы не будет. будет или группа или номенклатура

[mazzy]

Цитата:

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

Плюсы первого подхода:

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

так и вы - рассматриваете только хранение.

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

теперь подумайте как будут пользователи работать с вашими ссылками? как они будут фильтровать/сортировать? что программист должен будет сделать чтобы тупо показать эти "ссылки" пользователям и что пользователи будут делать с этими значениями.

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

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

[Ivanhoe]

Цитата:

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

Ну в стандарте если валидация прошла такой проблемы не будет. будет или группа или номенклатура

В чем проблема сделать и тут валидацию?

[Ivanhoe]

Цитата:

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

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

так и вы - рассматриваете только хранение.

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

теперь подумайте как будут пользователи работать с вашими ссылками? как они будут фильтровать/сортировать? что программист должен будет сделать чтобы тупо показать эти "ссылки" пользователям и что пользователи будут делать с этими значениями.

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

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

Про дома не будем, там вопрос реализации, а не идеи.

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

[Logger]

Почему- то никто не упомянул про случай когда у нас не 2 варианта "группа/все" а больше.
А также случай когда надо сделать кастомизацию и добавить еще пяток связей. И что будет с индексами и объемом.

[fed]

Я добавлю, что если уж совсем по науке и с полной нормализацией делать, то надо не одну таблицу делать, а несколько. В головной таблице держать enum с типом ссылки, в каждой дочерней таблице держать ссылку на головную таблицу (например по recId), и ссылку на определяющую сущность по какому-то другому ключу. Соответственно, например таблица профиля разноски по поставщику развалилась бы на три таблицы с разными ссылками - VendLedgerAccounts, VendLedgerAccountsVend, VendLedgerAccountsVendGroup.

Но как верно заметил mazzy, хотя нормализованная форма теоретически дает непротиворечивость и компактность хранения, она еще дает и бОльшую сложность для пользователя и бОльшие трудности с организацией интерфейса. Поэтому отцы-основатели из Damgaard выбрали имеющийся подход. Меня он вполне устраивает...

[Владимир Максимов]

Вы перепутали причину и следствие

Цель организации связи между таблицами в среде Axapta - это обеспечение некоторого автоматизма при написании модификаций. Например, при переходе к основой таблице через контекстное меню (по правой клавише мыши на поле в форме). Т.е. "тупо" для того, чтобы разработчику меньше кода писать надо было.

Цель использования Base Enum - это указание некоторого реквизита текущей записи таблицы

Тот факт, что Base Enum может быть указан в Relation - это "фича". Особенность. Вспомогательный, не основной, инструмент разработки

Предположим, у таблицы могут быть указаны "Сайт" и "Склад". Два поля.

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

Вы не может однозначно ответить на эти вопросы. Всегда будет некоторый элемент неопределенности. Всегда будет сомнение в корректности ввода данных.

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

Замечу, что начиная с версии Ax2012 связь более чем по 1 полю считается устаревшей. Оставлена для обратной совместимости и облегчения перехода разработчикам на новые версии. Сделать-то можно, но проверка по Best Practices будет ругаться нехорошими словами, что, дескать, так не надо

Т.е. в данном примере в Ax2012 по Best Practices как раз и надо будет сделать 3 поля: Base Enum, Сайт, Склад. И Relation будет по каждой таблице в отдельности + Base Enum как идентификатор того, с чем работать надо


Можно, конечно, рассматривать Base Enum как некую альтернативу использования TableId. Но следует иметь в виду, что в этом случае критерием связи становится не физическая сущность (таблица), а некая логическая сущность (документ или тип документа).

Совсем не обязательно, что разные значения Base Enum - это разные таблицы. Это вполне могут быть одни и те же таблицы, но являющиеся разными "документами". Например, разные типы складских журналов. Ну, или классический InventTableModule

[Ivanhoe]

Цитата:

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

Предположим, у таблицы могут быть указаны "Сайт" и "Склад". Два поля.

Уже второй раз этот аргумент. Если мы строим связи через эти поля, очевидно, не могут быть они заполнены одновременно. Также как всем очевидно, что в стандарте при указании "Номенклатура" в енуме, во втором поле будет НЕ группа, а код номенклатуры.

[Владимир Максимов]

Цитата:

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

Уже второй раз этот аргумент. Если мы строим связи через эти поля, очевидно, не могут быть они заполнены одновременно.

"А почему, собственно?" (с)

Факт заполнения обеих полей на собственно СВЯЗИ не влияет НИКАК. От слова "совсем"

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

Так почему вместо "вычислений" не указать это значение явно? Через дополнительный Base Enum?

Возвращаемся к примеру

Есть Base Enum со значениями: All/Group/Item

Цель и смысл существования этого поля? Разве для создания Relation? Вовсе нет! Его цель и смысл - это некий switch в программном коде. Некое "ветвление кода"

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

Ну, и как повлияет на КОД (тот самый switch) факт заполнения обеих полей? Это влияние возможно в том и только в том случае, если у Вас нет Base Enum и Вы вынуждены каким-то образом "вычислять" по какой ветке кода пойдет обработка. А вычисление - это всегда некоторая неопределенность

[EVGL]

С учетом того, что в AX7-AX8 большинство enumeration по умолчанию не расширяемые, а при попытке расширения целочисленное значение не фиксировано, то от подхода "Тип связи задается енумом" давно пора уходить. Бороться с ветряными мельницами в Редмонде и Фарго - себе дороже.

Ссылка: https://docs.microsoft.com/en-us/dyn...add-enum-value

[wojzeh]

Цитата:

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

никто не учитывал затраты на бензин при возвращении панелевозов порожняком со стройки

иногда тоже вот так, еду домой со стройки и чую: порожняк написал...

[KiselevSA]

Цитата:

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

С учетом того, что в AX7-AX8 большинство enumeration по умолчанию не расширяемые, а при попытке расширения целочисленное значение не фиксировано, то от подхода "Тип связи задается енумом" давно пора уходить. Бороться с ветряными мельницами в Редмонде и Фарго - себе дороже.

Ссылка: https://docs.microsoft.com/en-us/dyn...add-enum-value

Пропущено главное, на мой взгляд, "по возможности". Приведу рабочий бизнес-пример: справочник владельцев. Есть следующие варианты выбора владельца:
1. Поставщик - приобретенный комиссионный и собственный (поставщик = компания) товар;
2. Клиент - отданный на реализацию собственный товар;
3. Контактное лицо - ранее проданный товар, принятый на ремонт или диагностику;
4. Сотрудник - для дополнительного аналитического учета, например, при приобретении (отв.лицо) IT-техники и дальнейшей эксплуатации.
Мне кажется связка по enum является оптимальным вариантом, т.к. в зависимости от его значения могут использоваться совершенно разные сущности и разные способы инициализации остальных полей в справочнике.
Да и в случае справочника цен отказ от перечисления. как мне кажется, приведет к "головной боли" определения приоритетов выборки.

[pitersky]

Да, архитектура AX7 как бы уже сама подсказывает феншуйный ответ на этот вопрос
Сейчас связи между таблицами рекомендовано делать через foreign keys, то есть по RecId, причём на связанной таблице обязательно должен быть Replacement key, иначе на форме вместо человеческого значения будет отображаться RecId. Любая вставка енума разрушает foreign key и в форме всегда отображается именно RecId.
Так что надо или отказываться от новомодных релэйшнов, или для каждого типа использовать отдельное поле.

[Владимир Максимов]

Цитата:

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

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

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

Мы же про Relation говорим. Или нет?

[EVGL]

Цитата:

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

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

Мы же про Relation говорим. Или нет?

Пример: создание заголовка Sales quotation. Такие штуки есть и будут на SYS-слое, однако Quod licet Iovi, non licet bovi.