Показать сообщение отдельно
Старый 03.03.2013, 12:59   #17  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,892 / 5650 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от sukhanchik Посмотреть сообщение

Важно другое. Фактически - этим изменением на мой взгляд похоронили саму идею иерархии таблиц. Ну т.е. в "теоретических" головах разработчиков ядра системы - можно конечно рисовать иерархию таблиц, а вот на практике, на мой взгляд - никто не будет заморачиваться с этой иерарихей, когда можно тупо создать одну большую мегатаблицу. При этом не придется заморачиваться наследованием методов (раз таблица одна, значит и методы на ней все). Т.е. автоматически исчезает потребность создавать производные таблицы, как средство размещения кода (проще все разместить на одной таблице, нежели себя обманывать и плодить псевдо-таблицу, которой нет в БД).
Скорее - реализация была безумной. Разумный подход - это когда использование датасорца некоторого уровня иерархии размещает в запросе все датасорцы более высших уровней иерархии, соединенных обычным inner join. Идея, что помещение на форму родительской таблицы также помещает все дочерние с мега-аутер-джойном между ними - что-то из области фантастики. Остается только гадать что употребляли дизайнеры этой фичи - опиаты или каннабиойды...
Ну и конечно, при проектировании прикладной структуры, разработчики должны понимать что каждый дополнительный уровень иерархии таблиц обходится намного дороже чем дополнительный уровень иерархии при проектировании классов. Заводить еще один уровень иерархии из за 1-2-3 аттрибутов - слишком накладно.
За это сообщение автора поблагодарили: sukhanchik (3), S.Kuskov (2).