AX 2012 Наследование таблиц. Краткое описание механизма

[fed]

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

[pitersky]

Цитата:

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

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

А зачем? По мне, так наоборот - пусть всё физически лежит в одной таблице, а логически/визуально - разделяется

[fed]

Цитата:

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

А зачем? По мне, так наоборот - пусть всё физически лежит в одной таблице, а логически/визуально - разделяется

Ну разрастание числа полей в таблице - тоже не подарок с точки зрения производительности. Если некоторая дочерняя сущность содержит 20-30 полей и составляет менее чем 10% от родительской таблицы - есть большой резон выложить ее в дочернюю таблицу. Поскольку при таких раскладах, накладняк на джойны будет перевешен экономией времени на доступе к оставшимся 90% записей. Лишние поля в таблицах - они тоже не бесплатны с точки зрения времени доступа и занимаемого пространства. Опять таки - про обновление лишних индексов по родительской таблице стоит подумать...
Короче говоря - нормализацию не просто так придумали. Просто нужно не доводить ее до абсурда...

[sukhanchik]

Цитата:

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

Ну разрастание числа полей в таблице - тоже не подарок с точки зрения производительности. Если некоторая дочерняя сущность содержит 20-30 полей и составляет менее чем 10% от родительской таблицы - есть большой резон выложить ее в дочернюю таблицу. Поскольку при таких раскладах, накладняк на джойны будет перевешен экономией времени на доступе к оставшимся 90% записей. Лишние поля в таблицах - они тоже не бесплатны с точки зрения времени доступа и занимаемого пространства. Опять таки - про обновление лишних индексов по родительской таблице стоит подумать...
Короче говоря - нормализацию не просто так придумали. Просто нужно не доводить ее до абсурда...

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

[fed]

Цитата:

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

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

Нет. Если ты в базовую таблицу засовываешь, допустим, 80 дополнительных полей, они (даже если там нет данных), будут занимать какое-то (пусть небольшое) место в записи. Чем больше средний размер записи, тем большее количество страниц должен прочитать сервер при извлечении данных.
Кроме того - если мы добавим совсем уж много полей в базовую таблицу, то дочерние индексы тоже надо будет по ней строить. Это слегка усилит накладняк на обновление (не во всех случаях, но, в общем, в каких-то случаях - может увеличить).

[sukhanchik]

Цитата:

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

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

А смысл? Если физическое хранение полей в ней - то возвращаемся к тому, что было в АХ 2012 без R2. Т.е. с кучей джойнов.
Т.е. какой резон давать выбор? Опять-таки - я смотрю глазами практика, который не будет лишний раз заморачиваться с реализацией, если есть возможность не заморачиваться .
Что дадут джойны ? Даже в случае с LedgerJournalTrans, где такая архитектура может быть оправдана - там лишние джойны явно не приведут к увеличению производительности.