|
03.03.2013, 22:22 | #1 |
Роман Долгополов (RDOL)
|
Сам, увы, по нормальному с DAX2012 так и не работал, поэтому выскажусь на "общечеловескую" тематику основываясь на предыдущих сообщениях темы.
Чтобы понять что случилось надо рассмотреть возможные варианты отображения иерархий классов в таблицы БД. Применительно к DAX таблица в AOT с полями и методами это "класс", а соответствующая таблица в БД это просто "таблица" Несомненно наличие механизма отображения иерархий классов в реляционные бд вещь полезная, хоть и не жизненно необходимая Существуют три общепринятых способа такого отображения 1. Для каждого класса иерархии своя таблица в БД, содержащая только поля данного класса + прямолинейное отображение классов в таблицы, нет лишних полей, экономия пространства - чтобы получить данные конкретного класса нужен join - при измении структуры классов, перемещении полей надо следом всё это повторять в бд, т.е. физически перемещать поля между таблицами вместе с данными 2. Для каждого конкретного (неабстрактного) класса своя таблица в БД, содержащая все поля как данного класса, так и всех предков + Лишнего места (как и первый вариант) не занимает + Нет джойнов - Для построения каких либо отчетов и прочих операциях по промежуточному уровню иерархии появляется union - Так же как и в случае с первым вариантом изменения структуры классов приводят в необходимости следом изменить структуру таблиц, причем так как поля дублируются во многих таблицах, всё еще гораздо "запущеннее" - Проблемы с уникальностью ключевых полей. Так как индекс на каждой таблице свой, а constrain-ы привязаны к индексу, весьма вероятны задвоения значений ключевых полей. Т.е. БД перестает даже помогать управлять уникальностью значений и это должно быть реализовано в приложении 3. Для всей иерархии одна таблица в БД, содержащая все поля всех классов иерархии + Никаких: join, union, проблем с уникальностью, проблем с поддержкой изменений иерархии - Не оптимальное расходования места (хотя некоторые бд умеют более умно хранить дефолтные значения столбцов и места пропадает меньше) Вариант 1 теоретически красив, радует глаз и сердце архитектора и в идеальном объектом мире идеален. Джойны? так СУБД умеет джойнить. Надо тасовать данные при изменении иерархии? А для для чего еще нужны БД, если не для этого. И этот вариант как раз то что появилось в DAX2012. Всё по учебнику, всё красиво и "супер-супер". Реальный мир, как обычно, практичен и несовершенен. Тучи джойнов напрягают сервера, но не это самое страшное. А вот когда поле передвинули в иерархии и это приводит к необходимости следом переносить столбцы вместе с данными между таблицами, то это уже очень невесело для реальной жизни. Сделать такие изменения "на ходу" даже теоретически непросто и не быстро, не говоря уже о системе 24x7. Дополнительным "увеселителем" ситуации выступают всякие кубы/порталы/репортинг сервисы и прочие примкнувшие приложения, которые мало или вообще ничего не знают о метаданных DAX, а полагаются в основном на ее БД и дружно отказываются работать при изменении ее структуры. Механизм наследования таблиц сам по себе уж точно не лишнее для DAX. Поэтому решение перейти на 3 вариант, вернув одну широкую таблицу в БД, но оставить все остальное на месте вполне разумный шаг и, по сути, признание своих ошибок. И хотя бы это радует. Учебники, между тем, настоятельно рекомендуют начинать именно с третьего варианта Последний раз редактировалось db; 03.03.2013 в 22:34. |
|
|
За это сообщение автора поблагодарили: mazzy (2), gl00mie (3), S.Kuskov (5). |
04.03.2013, 11:43 | #2 |
Moderator
|
Для того чтобы реализация механизма была идеальной, надо было бы просто добавить возможность в свойствах таблицы-наследника указывать место физического хранения ее полей - в отдельной таблице или в той же таблице что и поля родителя.
|
|
04.03.2013, 11:55 | #3 |
северный Будда
|
А зачем? По мне, так наоборот - пусть всё физически лежит в одной таблице, а логически/визуально - разделяется
__________________
С уважением, Вячеслав |
|
04.03.2013, 12:01 | #4 |
Moderator
|
Цитата:
Короче говоря - нормализацию не просто так придумали. Просто нужно не доводить ее до абсурда... |
|
04.03.2013, 12:08 | #5 |
Administrator
|
Цитата:
Сообщение от fed
Ну разрастание числа полей в таблице - тоже не подарок с точки зрения производительности. Если некоторая дочерняя сущность содержит 20-30 полей и составляет менее чем 10% от родительской таблицы - есть большой резон выложить ее в дочернюю таблицу. Поскольку при таких раскладах, накладняк на джойны будет перевешен экономией времени на доступе к оставшимся 90% записей. Лишние поля в таблицах - они тоже не бесплатны с точки зрения времени доступа и занимаемого пространства. Опять таки - про обновление лишних индексов по родительской таблице стоит подумать...
Короче говоря - нормализацию не просто так придумали. Просто нужно не доводить ее до абсурда...
__________________
Возможно сделать все. Вопрос времени |
|
04.03.2013, 12:14 | #6 |
Moderator
|
Цитата:
Кроме того - если мы добавим совсем уж много полей в базовую таблицу, то дочерние индексы тоже надо будет по ней строить. Это слегка усилит накладняк на обновление (не во всех случаях, но, в общем, в каких-то случаях - может увеличить). |
|
|
За это сообщение автора поблагодарили: sukhanchik (3). |
04.03.2013, 11:59 | #7 |
Administrator
|
Цитата:
Т.е. какой резон давать выбор? Опять-таки - я смотрю глазами практика, который не будет лишний раз заморачиваться с реализацией, если есть возможность не заморачиваться . Что дадут джойны ? Даже в случае с LedgerJournalTrans, где такая архитектура может быть оправдана - там лишние джойны явно не приведут к увеличению производительности.
__________________
Возможно сделать все. Вопрос времени |
|
04.03.2013, 12:22 | #8 |
Участник
|
Кстати об индексах. В дочерних таблицах можно в состав индекса включать поля из базовых таблиц? А если это две разные физические таблицы?
UPD: Получается, если это две разные физические таблицы, то это уже материализованное представление нужно делать. Чем по сути объединённая таблица и является Последний раз редактировалось S.Kuskov; 04.03.2013 в 12:32. |
|
01.05.2016, 22:45 | #9 |
Участник
|
Проясните плиз ситуацию с индексами (AX2012 R2). В индекс на базовой таблице нельзя включить поле из дочерней, а в индекс на дочерней таблице - поле из базовой. Как быть ? Надеяться что SQL сам построит оптимальный план запроса без моего индекса? Действует ли на дочернюю таблицу индекс из базовой ? (в смысле, всегда ли SQL использует этот индекс, если я делаю запрос к дочерней таблице с участием полей из базовой таблицы)
Цитата:
Сообщение от S.Kuskov
Кстати об индексах. В дочерних таблицах можно в состав индекса включать поля из базовых таблиц? А если это две разные физические таблицы?
UPD: Получается, если это две разные физические таблицы, то это уже материализованное представление нужно делать. Чем по сути объединённая таблица и является |
|
20.09.2018, 19:08 | #10 |
Участник
|
Привет всем.
Коллеги, столкнулся со странной вещью. Ax2012 R3 CU13 Открываю обозревателем табличку с наследованием. В логе запросов видно, что идет запрос с джоином к разным табличкам, т.е. данные в SQL физически хранятся как в Ax2012 RTM. Как такое может быть ? Версия точно Ax2012 R3 CU13 Рядом стоит другой аос с такой же версией, у него запросы нормально ходят. Побайтно сравнил exe / dll файлы аосов - все совпадает. Проверял на DirPartyTable и AgreementHeader. Первая мысль - странный аос поставлен в режиме апгрейда приложения с предыдущих версий. Может быть из-за этого включился какой-то режим совместимости и база при синхронизации использует старый формат хранения. Как от этого избавиться ? База создана slipstream инсталлятором. Последний раз редактировалось Logger; 20.09.2018 в 19:25. |
|
20.09.2018, 19:22 | #11 |
Участник
|
Есть догадка что это связано с конвертацией приложения базы, что так сделали программисты ядра чтобы не делать конвертацию с ax4/2009 на 2012/R3
Т.е. идет конвертация формата ax4/2009 --> 2012 RTM а потом 2012 RTM --> 2012 R3 И я заглянув под капот увидел промежуточное состояние когда ядро R3 при синхронизации использует формат хранения RTM. Но все равно хочется разобраться, тем более что выбран режим "Контрольный список обновления кода AOD". Контрольный список обновления данных еще не запускали. Последний раз редактировалось Logger; 20.09.2018 в 19:36. |
|
21.09.2018, 17:28 | #12 |
Участник
|
Разобрался в чем проблема.
Если база и аос устанавливается в режиме "Register database for upgrade from Microsoft Dynamics AX 4.0 or Microsoft Dynamics AX 2009" то инсталлятор прописывает в БД хранимку TABLEPERTYPEINHERITANCEMODE которая возвращает 1. Также в табличке SYSGLOBALCONFIGURATION создает запись с NAME = TABLEPERTYPEMODE После этого аос считает что иерархию табличек надо хранить как в RTM версии в режиме одна табличка на одну табличку иерархии. Указанный эффект можно получить если просто в обычной базе создать хранимку командой X++: USE [BASE_NAME]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[TABLEPERTYPEINHERITANCEMODE] AS SELECT 1
GO Касательно задачи конвертации базы из ax4/2009 в формат 2012 R3 - то судя по всему предположение (что конвертер с предыдущих версий конвертирует базу в RTM формат) оказалось правильным и база в 2012-й сперва создается в режиме TABLEPERTYPEINHERITANCEMODE (так как инсталлятор создает ее с хранимкой) а после импорта / конвертации данных из ax4/2009 запускается класс SysDataUpgradeSCscTPT2TPH который и конвертирует уже способ хранения табличек в "плоский" режим. А в конце грохает хранимку и запись в SYSGLOBALCONFIGURATION (см. методы getStoredProcCleanupStatement и isInUnFlattenMode). Последний раз редактировалось Logger; 21.09.2018 в 18:16. |
|
|
За это сообщение автора поблагодарили: sukhanchik (6), gl00mie (5), -DocSerzh- (1), S.Kuskov (2). |
21.09.2018, 17:56 | #13 |
Участник
|
Вот тут о том же речь в комментариях.
https://blogs.msdn.microsoft.com/axs...on-check-list/ |
|
Теги |
ax2012, inheritance, table inheritance, наследование таблиц, полезное |
|
|