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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 12.02.2018, 14:19   #1  
IKA is offline
IKA
Участник
 
359 / 65 (3) ++++
Регистрация: 15.03.2006
RefTableId vs RefTableName - что хранить в таблице?
Есть таблица - лог.
В ней нужно хранить ссылку на запись в другой таблице (события в которой спровоцировали запись в этот лог) и дать возможность пользователю возможность с записи в этом логе перейти на форму с таблицей-провокатором. Также пользователю нужно показать название таблицы (можо не Label , а TableName)

Таблиц-провокаторов несколько, поэтому в логе нужно хранить RefTableId+RefRecId или же RefTableName+RefRecId

По идее, вроде, обычно в Ax практикуется хранить связку RefTableId+RefRecId , но
1) Если я буду сохранять tableId, то все равно надо display-метод писать, чтобы показать RefTableName на grid формы, то есть, доп накладные расходы. Плюс, мне кажется, что такой метод не будет даже кэшироваться, тк это метаданные (см пример в AifCorrelation форме).
2) Вероятность, что кто-то имя таблицы поменяет - мала, а вот ID-конфликтов, намного выше, поэтому хранить RefTableName кажется надежней

В пользу RefTableId вижу размер поля на стороне DB (int vs nvarchar)....

Почему чаще используется подход хранить RefTableId? Я, быть может, упускаю что-то из виду? Как посоветуете сделать?

Спасибо

AX2012 R3
Старый 12.02.2018, 14:31   #2  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от IKA Посмотреть сообщение
Почему чаще используется подход хранить RefTableId?
Наверное потому что DictTable инициализируется через TableId, а не через TableName. В свойствах, узлах объектов в AOT в подавляющем большинстве хранятся Id а не имена. Попробуйте связать два элемента, а потом переименовать. Связь останется.

Применительно к задаче. Я бы сохранял оба значения. Денормализация - обычное дело для AX
Старый 12.02.2018, 15:07   #3  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Ничто не мешает вывести физическое поле с TableName из добавленного в DS SQLDictionary. Так что стандартный подход в данной задаче - самое то.
__________________
Ivanhoe as is..
Старый 12.02.2018, 16:08   #4  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,649 / 1146 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Опять же, что есть "правило" в данной системе? Не важно, по какой причине. А "правило" - это ссылка по коду, а не по имени. Все. На этом дискуссия заканчивается

Но если Вам нужен "обоснуй", то

1. Лог - это таблица, которая растет очень быстро. На то и "лог" Значит, для нее критически важным является размер одной строки. В байтах. Чем меньше, тем лучше

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

Как следствие, подтянуть дополнительные идентификаторы из связанных таблиц для просмотра - не проблема. И некоторое подтормаживание просмотра, также не критично. Как уже подсказали, можно подтянуть таблицу \System Documentation\Tables\SqlDictionary и отображать без дисплейных методов

3. Изменение id-таблицы? Ну, это вообще крах системы! Это Вы загнули. Возможно, конечно, но это будет глобальная проблема всей Axapta. Ошибки идентификации лога в этом случае Вас будет интересовать в последнюю очередь
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
За это сообщение автора поблагодарили: Ivanhoe (2).
Старый 12.02.2018, 16:56   #5  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
НО! Если вы хотите упаковать идентификатор таблицы в контейнер и сохранить/передать на другую инсталляцию, то лучше использовать TableName (table id - installation specific)
Старый 12.02.2018, 17:35   #6  
IKA is offline
IKA
Участник
 
359 / 65 (3) ++++
Регистрация: 15.03.2006
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Ничто не мешает вывести физическое поле с TableName из добавленного в DS SQLDictionary. Так что стандартный подход в данной задаче - самое то.
В AifCorrelation Бог, например, почему-то SqlDictionary не приджойнил ..

Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
В свойствах, узлах объектов в AOT в подавляющем большинстве хранятся Id а не имена.
Конечно. Но TableName2Id однозначно отображает Name в Id, поэтому можно сохранять и показывать поле, что имеет смысл для пользователя. А если уж решит посмотреть на источник конкретной строки, то получить TableId из Name (т.о меньше лишних накладных расходов на вычисления display методов или джойн)

Насчет длины согласна (и сразу написала) .... но тоже, в аксапте так безбожно везде добавляются строковые поля, что уж не вижу криминала тут строку добавить(или даже оба поля) , а не int, если эт оправдано. Лог будет периодически чиститься, поэтому скорость работы и удобство, по идее, важнее размера таблицы на стороне БД

Общая канва того, что нужно взвесить, ясна.
Всем большое спасибо!
Старый 12.02.2018, 17:57   #7  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от IKA Посмотреть сообщение
В AifCorrelation Бог, например, почему-то SqlDictionary не приджойнил ..
Это не MS ли в суе упомянут? Ладно там, а как вам SysDatabaseLog - верх архитектуры? Дисплейник на текстовое "название" таблицы с учетом иерархий и нормализаций/денормализаций, не говоря уже про кривой перевод в локализации...
__________________
Ivanhoe as is..
Старый 12.02.2018, 22:10   #8  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,271 / 3465 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
В D365 TableId даже стандартных таблиц отличаются между инсталляциями (по крайней мере в моем случае так). Так что если смотреть на будущее, я бы использовал только TableName для хранения и ни в коем случае не TableId (в старых версиях слетание ID-шников все же чаще происходит, нежели слетание имени, поэтому там тоже я использовал TableName, в т.ч. для целей удобства просмотра / переноса данных
__________________
Возможно сделать все. Вопрос времени
Старый 12.02.2018, 22:29   #9  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
В новой версии в принципе нормальный перенос данных возможен только с копией бд модели.
__________________
Ivanhoe as is..
Старый 16.02.2018, 10:32   #10  
CDR is offline
CDR
MCTS
MCBMSS
 
236 / 175 (6) ++++++
Регистрация: 27.11.2003
Цитата:
Сообщение от IKA Посмотреть сообщение
Есть таблица - лог.
В ней нужно хранить ссылку на запись в другой таблице (события в которой спровоцировали запись в этот лог) и дать возможность пользователю возможность с записи в этом логе перейти на форму с таблицей-провокатором. Также пользователю нужно показать название таблицы (можо не Label , а TableName)

Таблиц-провокаторов несколько, поэтому в логе нужно хранить RefTableId+RefRecId или же RefTableName+RefRecId

По идее, вроде, обычно в Ax практикуется хранить связку RefTableId+RefRecId , но
1) Если я буду сохранять tableId, то все равно надо display-метод писать, чтобы показать RefTableName на grid формы, то есть, доп накладные расходы. Плюс, мне кажется, что такой метод не будет даже кэшироваться, тк это метаданные (см пример в AifCorrelation форме).
2) Вероятность, что кто-то имя таблицы поменяет - мала, а вот ID-конфликтов, намного выше, поэтому хранить RefTableName кажется надежней

В пользу RefTableId вижу размер поля на стороне DB (int vs nvarchar)....

Почему чаще используется подход хранить RefTableId? Я, быть может, упускаю что-то из виду? Как посоветуете сделать?

Спасибо

AX2012 R3
А вариант с Enum, как в таблице InventTransOrigin, например, чем не устраивает?
Возникновение потребности хранить в БД tableId или classId - первый признак design error. Редкий пользователь попросит вывести ему на форму внутренний идентификатор таблицы или ее системное имя. Как правило, это решение программиста или консультанта, которые смотрят на мир через AOT и которым, соответственно, так проще. Пользователь, обычно, предпочитает видеть человеческое название соответствующего документа или справочника.

К тому же, использование enum дает возможность разделить документы, использующую одну и ту же таблицу (складской журнал проводка от складского журнала инвентаризации или журнал платежей от журнала кассовых ордеров).
__________________
Dynamics AX Experience
За это сообщение автора поблагодарили: mazzy (10).
Старый 16.02.2018, 10:59   #11  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от CDR Посмотреть сообщение
А вариант с Enum, как в таблице InventTransOrigin, например, чем не устраивает?
Так наверно думали разработчики DMF когда создавали enum со списком DMF entities. Зачем вам больше 255 ?
Вот и автору зачем логировать более 255 таблиц? Все это от лешего
За это сообщение автора поблагодарили: Vadik (1), sukhanchik (2), S.Kuskov (2).
Старый 16.02.2018, 11:25   #12  
CDR is offline
CDR
MCTS
MCBMSS
 
236 / 175 (6) ++++++
Регистрация: 27.11.2003
Цитата:
Сообщение от skuull Посмотреть сообщение
Так наверно думали разработчики DMF когда создавали enum со списком DMF entities. Зачем вам больше 255 ?
У меня вообще большие сомнения, что разработчики DMF думали о том, о чем нужно было.
__________________
Dynamics AX Experience
Старый 16.02.2018, 11:28   #13  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от skuull Посмотреть сообщение
Так наверно думали разработчики DMF когда создавали enum со списком DMF entities. Зачем вам больше 255 ?
Вот и автору зачем логировать более 255 таблиц? Все это от лешего
Ну если нужно так много, чем не подходит DatabaseLog?

Я соглашусь с CDR, что сценарий использования важно определить и действительно может быть более правильным использовать enum.
__________________
Ivanhoe as is..
Старый 16.02.2018, 21:36   #14  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Ну если нужно так много, чем не подходит DatabaseLog?

Я соглашусь с CDR, что сценарий использования важно определить и действительно может быть более правильным использовать enum.
255 это не много по сравнению с общим количеством и получится как всегда, фичу сделали классную но использовать ее можно только в 2х местах, а в третьем уже надо пилить напильником. Да и мапить надо где-то значение enum с таблицей, что есть лишний код. Хороший дизайн, безошибочный.

Почему не Database log нам должен сказать автор, мы то задачи не знаем, может и он сойдёт.
За это сообщение автора поблагодарили: sukhanchik (4).
Старый 24.02.2018, 00:22   #15  
IKA is offline
IKA
Участник
 
359 / 65 (3) ++++
Регистрация: 15.03.2006
Автор отвечает:
DatabaseLog лог не годится, тк эта модицикация - по сути логирование ошибок при обработке данных по некоторым таблицам, а не ins/upd/del лог
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Фильтрование записей при "переходе к основной таблице" demID DAX: Программирование 10 18.11.2015 12:52
Переименование полей в одной таблице на основе данных из другой niksen DAX: Программирование 1 14.09.2011 12:34
Как лучше хранить ссылки на записи - (RefTableId, Company, RefRecId) mazzy DAX: Программирование 41 08.07.2011 13:18
Как хранить RTF или DOC в таблице listener DAX: Программирование 6 01.08.2003 19:25
фильтр по связанной таблице mick_777 DAX: Программирование 13 21.08.2002 16:00
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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