12.02.2018, 14:19 | #1 |
Участник
|
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 |
Участник
|
Наверное потому что DictTable инициализируется через TableId, а не через TableName. В свойствах, узлах объектов в AOT в подавляющем большинстве хранятся Id а не имена. Попробуйте связать два элемента, а потом переименовать. Связь останется.
Применительно к задаче. Я бы сохранял оба значения. Денормализация - обычное дело для AX |
|
12.02.2018, 15:07 | #3 |
Участник
|
Ничто не мешает вывести физическое поле с TableName из добавленного в DS SQLDictionary. Так что стандартный подход в данной задаче - самое то.
__________________
Ivanhoe as is.. |
|
12.02.2018, 16:08 | #4 |
Участник
|
Опять же, что есть "правило" в данной системе? Не важно, по какой причине. А "правило" - это ссылка по коду, а не по имени. Все. На этом дискуссия заканчивается
Но если Вам нужен "обоснуй", то 1. Лог - это таблица, которая растет очень быстро. На то и "лог" Значит, для нее критически важным является размер одной строки. В байтах. Чем меньше, тем лучше 2. Лог - это информация на случай возникновения не штатных ситуаций, чтобы выяснить, что послужило причиной возникновения проблемы. Т.е., как правило, используется относительно редко. Как следствие, подтянуть дополнительные идентификаторы из связанных таблиц для просмотра - не проблема. И некоторое подтормаживание просмотра, также не критично. Как уже подсказали, можно подтянуть таблицу \System Documentation\Tables\SqlDictionary и отображать без дисплейных методов 3. Изменение id-таблицы? Ну, это вообще крах системы! Это Вы загнули. Возможно, конечно, но это будет глобальная проблема всей Axapta. Ошибки идентификации лога в этом случае Вас будет интересовать в последнюю очередь
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
За это сообщение автора поблагодарили: Ivanhoe (2). |
12.02.2018, 16:56 | #5 |
Участник
|
НО! Если вы хотите упаковать идентификатор таблицы в контейнер и сохранить/передать на другую инсталляцию, то лучше использовать TableName (table id - installation specific)
|
|
12.02.2018, 17:35 | #6 |
Участник
|
Цитата:
Цитата:
Насчет длины согласна (и сразу написала) .... но тоже, в аксапте так безбожно везде добавляются строковые поля, что уж не вижу криминала тут строку добавить(или даже оба поля) , а не int, если эт оправдано. Лог будет периодически чиститься, поэтому скорость работы и удобство, по идее, важнее размера таблицы на стороне БД Общая канва того, что нужно взвесить, ясна. Всем большое спасибо! |
|
12.02.2018, 17:57 | #7 |
Участник
|
Это не MS ли в суе упомянут? Ладно там, а как вам SysDatabaseLog - верх архитектуры? Дисплейник на текстовое "название" таблицы с учетом иерархий и нормализаций/денормализаций, не говоря уже про кривой перевод в локализации...
__________________
Ivanhoe as is.. |
|
12.02.2018, 22:10 | #8 |
Administrator
|
В D365 TableId даже стандартных таблиц отличаются между инсталляциями (по крайней мере в моем случае так). Так что если смотреть на будущее, я бы использовал только TableName для хранения и ни в коем случае не TableId (в старых версиях слетание ID-шников все же чаще происходит, нежели слетание имени, поэтому там тоже я использовал TableName, в т.ч. для целей удобства просмотра / переноса данных
__________________
Возможно сделать все. Вопрос времени |
|
12.02.2018, 22:29 | #9 |
Участник
|
В новой версии в принципе нормальный перенос данных возможен только с копией бд модели.
__________________
Ivanhoe as is.. |
|
16.02.2018, 10:32 | #10 |
MCTS
|
Цитата:
Сообщение от 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 Возникновение потребности хранить в БД tableId или classId - первый признак design error. Редкий пользователь попросит вывести ему на форму внутренний идентификатор таблицы или ее системное имя. Как правило, это решение программиста или консультанта, которые смотрят на мир через AOT и которым, соответственно, так проще. Пользователь, обычно, предпочитает видеть человеческое название соответствующего документа или справочника. К тому же, использование enum дает возможность разделить документы, использующую одну и ту же таблицу (складской журнал проводка от складского журнала инвентаризации или журнал платежей от журнала кассовых ордеров).
__________________
Dynamics AX Experience |
|
|
За это сообщение автора поблагодарили: mazzy (10). |
16.02.2018, 10:59 | #11 |
Участник
|
|
|
|
За это сообщение автора поблагодарили: Vadik (1), sukhanchik (2), S.Kuskov (2). |
16.02.2018, 11:25 | #12 |
MCTS
|
У меня вообще большие сомнения, что разработчики DMF думали о том, о чем нужно было.
__________________
Dynamics AX Experience |
|
16.02.2018, 11:28 | #13 |
Участник
|
Цитата:
Я соглашусь с CDR, что сценарий использования важно определить и действительно может быть более правильным использовать enum.
__________________
Ivanhoe as is.. |
|
16.02.2018, 21:36 | #14 |
Участник
|
Цитата:
Почему не Database log нам должен сказать автор, мы то задачи не знаем, может и он сойдёт. |
|
|
За это сообщение автора поблагодарили: sukhanchik (4). |
24.02.2018, 00:22 | #15 |
Участник
|
Автор отвечает:
DatabaseLog лог не годится, тк эта модицикация - по сути логирование ошибок при обработке данных по некоторым таблицам, а не ins/upd/del лог |
|