AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

Результаты опроса: Какой метод связи нескольких таблиц Вы предпочитаете?
Тип связи задается енумом. Значение связи в одном поле 8 53.33%
Связь задается в отдельных полях. Тип связи определяется заполненностью полей 3 20.00%
Мне все равно. Как сделают постановку задачи так и будет 4 26.67%
Голосовавшие: 15. Вы ещё не голосовали в этом опросе

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 12.08.2018, 22:52   #1  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
Теоретический вопрос. Варианты связи таблиц.
Здравствуйте.

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

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

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

....
Какие будут мысли у сообщества?
За это сообщение автора поблагодарили: ax_mct (3).
Старый 13.08.2018, 02:07   #2  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от ta_and Посмотреть сообщение
Если задано значение в первом поле - делается ссылка на группу. Если задано значение во втором поле - ссылка на номенклатуру. Если оба пустые - ссылок нет.
А если значение задано в обоих и номенклатура не принадлежит указанной группе?
Старый 13.08.2018, 06:02   #3  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
885 / 389 (14) ++++++
Регистрация: 24.01.2005
Адрес: Томск
Цитата:
Сообщение от trud Посмотреть сообщение
А если значение задано в обоих и номенклатура не принадлежит указанной группе?
Не мешайте людям устраивать забеги по граблям.

Ничто так не приближает к просветлению, как шишки на собственном лбу и работа по исправлению последствий собственных неоднозначных решений
__________________
Мы летаем, кружимся, нагоняем ужасы ...
За это сообщение автора поблагодарили: vmoskalenko (1).
Старый 13.08.2018, 08:47   #4  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от trud Посмотреть сообщение
А если значение задано в обоих и номенклатура не принадлежит указанной группе?
Те же вопросы к стандартному подходу.
__________________
Ivanhoe as is..
Старый 13.08.2018, 08:48   #5  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
Не мешайте людям устраивать забеги по граблям.

Ничто так не приближает к просветлению, как шишки на собственном лбу и работа по исправлению последствий собственных неоднозначных решений
Конструктивно. А по делу?
__________________
Ivanhoe as is..
Старый 13.08.2018, 09:14   #6  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Те же вопросы к стандартному подходу.
Ну в стандарте если валидация прошла такой проблемы не будет. будет или группа или номенклатура
Старый 13.08.2018, 09:25   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от ta_and Посмотреть сообщение
Плюсы первого подхода:
в советское время примерно так же считали экономическую выгоду от панельных домов - получалась дикая экономия массового производства панелей. просто никто не учитывал затраты на бензин при возвращении панелевозов порожняком со стройки и не учитывал затраты на восполнение теплопотерь в панельных домах и прочее. не говоря уже о простом удобстве проживания в панельных домах.

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

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

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

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

если же вам действительно интересна поднятая вами тема, то поищите по ключевым словам "естественные и искусственные ключи". тема обсасывалась и холиварилась с 80х годов прошлого века. написаны тонны материалов в обоснование и мегатонны критики обоих подходов.
__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили: wojzeh (1).
Старый 13.08.2018, 09:31   #8  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от trud Посмотреть сообщение
Ну в стандарте если валидация прошла такой проблемы не будет. будет или группа или номенклатура
В чем проблема сделать и тут валидацию?
__________________
Ivanhoe as is..
Старый 13.08.2018, 09:35   #9  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от mazzy Посмотреть сообщение
в советское время примерно так же считали экономическую выгоду от панельных домов - получалась дикая экономия массового производства панелей. просто никто не учитывал затраты на бензин при возвращении панелевозов порожняком со стройки и не учитывал затраты на восполнение теплопотерь в панельных домах и прочее. не говоря уже о простом удобстве проживания в панельных домах.

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

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

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

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

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

Какие выгоды сейчас есть в интерфейсе у пользователя? Он может быстро найти настройку разноски по номенклатуре открыв простую форму с гридом со всеми настройками и применив фильтр? Нет, он открывает специально заточенную форму и ищет там глазками. Это очень не удобно. Я уж молчу про код, когда система ищет сначала так, потом так, потом вот эдак...
__________________
Ivanhoe as is..
За это сообщение автора поблагодарили: ta_and (4), Logger (1).
Старый 13.08.2018, 09:49   #10  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Почему- то никто не упомянул про случай когда у нас не 2 варианта "группа/все" а больше.
А также случай когда надо сделать кастомизацию и добавить еще пяток связей. И что будет с индексами и объемом.
За это сообщение автора поблагодарили: Pandasama (1).
Старый 13.08.2018, 10:27   #11  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Я добавлю, что если уж совсем по науке и с полной нормализацией делать, то надо не одну таблицу делать, а несколько. В головной таблице держать enum с типом ссылки, в каждой дочерней таблице держать ссылку на головную таблицу (например по recId), и ссылку на определяющую сущность по какому-то другому ключу. Соответственно, например таблица профиля разноски по поставщику развалилась бы на три таблицы с разными ссылками - VendLedgerAccounts, VendLedgerAccountsVend, VendLedgerAccountsVendGroup.

Но как верно заметил mazzy, хотя нормализованная форма теоретически дает непротиворечивость и компактность хранения, она еще дает и бОльшую сложность для пользователя и бОльшие трудности с организацией интерфейса. Поэтому отцы-основатели из Damgaard выбрали имеющийся подход. Меня он вполне устраивает...
Старый 13.08.2018, 13:25   #12  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Вы перепутали причину и следствие

Цель организации связи между таблицами в среде 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
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
За это сообщение автора поблагодарили: Pandasama (1).
Старый 13.08.2018, 13:32   #13  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение

Предположим, у таблицы могут быть указаны "Сайт" и "Склад". Два поля.
Уже второй раз этот аргумент. Если мы строим связи через эти поля, очевидно, не могут быть они заполнены одновременно. Также как всем очевидно, что в стандарте при указании "Номенклатура" в енуме, во втором поле будет НЕ группа, а код номенклатуры.
__________________
Ivanhoe as is..
Старый 13.08.2018, 13:53   #14  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Уже второй раз этот аргумент. Если мы строим связи через эти поля, очевидно, не могут быть они заполнены одновременно.
"А почему, собственно?" (с)

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

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

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

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

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

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

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

Ну, и как повлияет на КОД (тот самый switch) факт заполнения обеих полей? Это влияние возможно в том и только в том случае, если у Вас нет Base Enum и Вы вынуждены каким-то образом "вычислять" по какой ветке кода пойдет обработка. А вычисление - это всегда некоторая неопределенность
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 13.08.2018, 13:57   #15  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
С учетом того, что в AX7-AX8 большинство enumeration по умолчанию не расширяемые, а при попытке расширения целочисленное значение не фиксировано, то от подхода "Тип связи задается енумом" давно пора уходить. Бороться с ветряными мельницами в Редмонде и Фарго - себе дороже.

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

Последний раз редактировалось EVGL; 13.08.2018 в 14:03.
За это сообщение автора поблагодарили: ta_and (4), trud (1), Logger (3).
Старый 13.08.2018, 16:40   #16  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
672 / 512 (19) +++++++
Регистрация: 27.04.2006
Адрес: Montreal
Цитата:
Сообщение от mazzy Посмотреть сообщение
никто не учитывал затраты на бензин при возвращении панелевозов порожняком со стройки
иногда тоже вот так, еду домой со стройки и чую: порожняк написал...
__________________
Felix nihil admirari
За это сообщение автора поблагодарили: eugene egorov (2).
Старый 14.08.2018, 08:40   #17  
KiselevSA is offline
KiselevSA
Злыдни
Аватар для KiselevSA
Злыдни
Лучший по профессии 2015
 
958 / 333 (13) ++++++
Регистрация: 25.01.2002
Адрес: Москва
Цитата:
Сообщение от EVGL Посмотреть сообщение
С учетом того, что в AX7-AX8 большинство enumeration по умолчанию не расширяемые, а при попытке расширения целочисленное значение не фиксировано, то от подхода "Тип связи задается енумом" давно пора уходить. Бороться с ветряными мельницами в Редмонде и Фарго - себе дороже.

Ссылка: https://docs.microsoft.com/en-us/dyn...add-enum-value
Пропущено главное, на мой взгляд, "по возможности". Приведу рабочий бизнес-пример: справочник владельцев. Есть следующие варианты выбора владельца:
1. Поставщик - приобретенный комиссионный и собственный (поставщик = компания) товар;
2. Клиент - отданный на реализацию собственный товар;
3. Контактное лицо - ранее проданный товар, принятый на ремонт или диагностику;
4. Сотрудник - для дополнительного аналитического учета, например, при приобретении (отв.лицо) IT-техники и дальнейшей эксплуатации.
Мне кажется связка по enum является оптимальным вариантом, т.к. в зависимости от его значения могут использоваться совершенно разные сущности и разные способы инициализации остальных полей в справочнике.
Да и в случае справочника цен отказ от перечисления. как мне кажется, приведет к "головной боли" определения приоритетов выборки.
__________________
люди...считают, что если техника не ломается, то ее не нужно ремонтировать. Инженеры считают, что если она не ломается, то нуждается в совершенствовании.
Старый 14.08.2018, 09:42   #18  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,486 / 408 (16) +++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Да, архитектура AX7 как бы уже сама подсказывает феншуйный ответ на этот вопрос
Сейчас связи между таблицами рекомендовано делать через foreign keys, то есть по RecId, причём на связанной таблице обязательно должен быть Replacement key, иначе на форме вместо человеческого значения будет отображаться RecId. Любая вставка енума разрушает foreign key и в форме всегда отображается именно RecId.
Так что надо или отказываться от новомодных релэйшнов, или для каждого типа использовать отдельное поле.
__________________
С уважением,
Вячеслав
За это сообщение автора поблагодарили: EVGL (2).
Старый 14.08.2018, 10:43   #19  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от KiselevSA Посмотреть сообщение
Мне кажется связка по enum является оптимальным вариантом, т.к. в зависимости от его значения могут использоваться совершенно разные сущности и разные способы инициализации остальных полей в справочнике.
А можно пример того, как Relation, созданный с учетом Enum, позволяет делать выбор при инициализации?

Мы же про Relation говорим. Или нет?
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 14.08.2018, 12:54   #20  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
А можно пример того, как Relation, созданный с учетом Enum, позволяет делать выбор при инициализации?

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

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Отображение связи n:n на форме mazzy DAX: Программирование 22 16.03.2011 16:19
Вопрос на подумать Vitali_i DAX: Программирование 2 01.02.2008 17:16
Вопрос по Проектам PSA DAX: Функционал 35 19.01.2007 22:26
Теоретический вопрос - все таки, как хранятся формы по с лоям? Romb DAX: Программирование 2 01.06.2005 08:35
расчеты с персоналом. НДФЛ. вопрос чайника shumelka DAX: Функционал 2 25.03.2004 11:36
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 13:26.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.