Оver-engineering - "зачем так сложно?"

[gl00mie]

Цитата:

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

По моему, главная проблема с наследованием таблиц в Ax - это решение о том что родитель содержит в себе все поля всех наследников. Из за этого им пришлось в ранних версиях автоматически делать outer join родителя ко всем наследникам, а в поздних версиях - просто складывать все поля наследников в одну большую таблицу-родителя.

Так была ведь задача выбрать запись из иерархии таблиц, не зная изначально точный "тип" записи, а потом, уже после выборки, иметь возможность сделать приведение типа к нужному наследнику и дальше работать с записью таблицы-наследника без перевыборки данных. Вариант с кучей outer join'ов оказался нежизнеспособным с т.з. производительности, пришли к одной таблице с полями всех-всех наследников, в которых могут быть значения NULL. Какие еще были варианты решить исходную задачу?..

Цитата:

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

В классической системе мэппинга объектных отношений в реляционную БД, обращение к таблице наследнику, неявно делает inner join с таблицей родителем. В обращение к родителю ни к каким автоматическим join не приводит.

Это хорошо работает, если заранее знать конкретный тип сущности, к которой идет обращение, и если не стоит задача последующего приведения типа родителя к наследнику.
Собственно, чем именно не нравится то, как это реализовано в Аксапте? Да, ядро всегда выбирает набор полей, равный объединению множеств полей всех таблиц-наследников для типа, "через который" идет обращение к таблице в иерархии. Так, если выбирать записи через DirPartyTable, то в выборку попадет под 150 полей (не считая DEL_-полей). Но если заранее более точно знать тип и выбирать, к примеру, DirPerson, то в выборке будет уже лишь 40 полей. При этом выборка через DirPartyTable даст в тех или иных записях кучу полей, содержащих NULL, ну и что с того? Длину строки SQL-запроса это увеличивает, но лишних данных, кроме тех, которые могут понадобиться для приведения к типам-наследникам, не гоняет.

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

[fed]

Цитата:

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

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

Ну по моему - такая ситуация и случается в большинстве случаев. Если нужно сделать какой-то универсальный обработчик, то разумнее пробежаться в таблице супео-класса, и тупо потом найти конкретные потомки find'ом. А при нынешнем подходе, оно вытаскивает вообще всех потомков, хотя у меня в обработчике может быть логика только для 2-3 кейзов (а тяжелый outer join строится для всех кейзов, а не только для тех, которые мне реально нужны).

[gl00mie]

Ядро и реализует универсальный обработчик - не ошибешься уже Пусть при этом вытаскиваются 150 полей вместо 40, но половина из них содержит NULL, т.е. доп.расходы на "лишний" трафик не столь велики, зато для корректного приведения типа отпадает необходимость повторно обращаться к БД и получать причитающиеся задержки на этом, а также переписывать бизнес-логику для перечитывания данных со всеми вытекающими последствиями, если где-то забыть это сделать.
Опять-таки, тяжелых outer join'ов нет со времен выхода AX 2012 R2, т.е. с декабря 2012-го года, а кто до сих пор работает на AX 2012 RTM - ну извините...
Вот ограничения по индексам - это, как мне кажется, куда серьезнее