mcureenabЧем гибче связь, чем больше степеней свободы и состояний она допускает, тем больше усилий нужно прилагать для её создания, тестирования и сопровождения.
Мне кажется, это утверждение обусловлено некоторой путаницей в понятиях. Попробую объяснить.

Давайте явно договоримся о терминологии: есть классы (то, что обычно подразумевается в ЯП - тип данных, если угодно компонент, обладающий определенными возможностями) и есть объекты (конкретные, созданные и настроенные экземпляры типа данных "класс").

Гибкость - это характеристика класса, не объекта. Гибкость означает примерно следующее: "а я могу создать и такую связь, и такую связь, и вот такую связь, и даже вот так вывернутую, просунутую, и трижды завязанную на конце связь".

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

Использование гибкого класса по трудоемкости мало отличается от использования для той же цели аналогичного негибкого класса. Можно не слишком отступив от истины сказать, что если для настройки объекта негибкого класса следует задать значения N свойств, то для аналогичной настройки объекта гибкого класса следует выбрать вариант поведения и настроить те же N свойств (то есть в сумме получается - настроить N+1 свойство). Разницы в трудоемкости тестирования - никакой (следует выполнить те же самые N тестов и проверить результаты). А вот в стоимости сопровождения проявляются преимущества гибкой связи: для решения задач, которые при гибком фреймворке решаются простейшей донастройкой, при негибком требуются нехилые усилия. Собственно, эти преимущества проявляются и при начальной разработке, но там они могут быть смикшированы искусным проектированием - в то время как в ходе сопровождения возникают задачи, "не очень ложащиеся" в исходную модель.

mcureenabОтображение данных, как правило самая простая наименее ограниченная задача.
И? Во всех примерах, которые я приводил, данные не только и не столько отображались. В том числе в том примере, в котором Вы ставили крестик.

mcureenabКомпоненты допускающие изменение данных наиболее сложная и капризная часть системы, в частности, требования к нормализации реляционных отношений исходят именно от задач изменения данных.
Вспомните тот же пример, в котором Вы ставили крестик. Где там капризная часть? В обоих случаях для модификации вызывается одна и та же ХП, в тексте которой не меняется ни один байт. Нормализация... какая нормализация? Об этом думает программист ХП; тот программист, который делает формы, от "нормализации" ну нисколько не зависит.

andr_kПлюс производительность системы требует пересмотра структур.
Требует. И как правило оставляет неизменным интерфейс.

_модА вот классификаторы объектов можно считать всегда иерархическими
... фасетные классификаторы стройными рядами отправились курить бамбук ...