Скрытые проблемы при моделировании данных с использованием бизнес-объектов

Question

Общий подход к моделированию данных заключается в использовании инструмента моделирования данных (например, Эрвина) для генерации схемы, а затем из схемы для генерации бизнес-объектов с использованием объектно-реляционного сопоставителя (ORM).

Менее распространенным является обратный процесс, в котором моделирование данных выполняется с использованием бизнес-объектов (например, POCO / POJO), из которых схема генерируется с использованием ORM.

Этот вопрос задается в отношении нетривиальных систем, которые содержат сотни таблиц базы данных.

У меня сложилось впечатление, что многие дизайнеры / архитекторы избегают второго подхода из-за ряда скрытых проблем, например, переноса данных между ревизиями схемы, уменьшения контроля над проектированием и настройкой запросов SQL. Каковы реальные проблемы?

Answer 1

Обычно для меня реальная проблема заключается в следующем утверждении:

"Этот вопрос задается в отношении нетривиальные системы, которые включают сотни таблиц базы данных. "

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

Обратите внимание, что если у вас есть «система, которая состоит из таблиц базы данных», вы должны говорить не об одной системе / контексте, а о наборе приложений / контекстов. Независимо от того, если в конце концов вы в итоге поместите одну и ту же БД, сложность решается тем, что вы не смоделируете ее как одну огромную вещь, которая в единую огромную БД. Ограниченный контекст - это модное слово в наше время.

Начиная с POCO, не означает, что в дальнейшем вы не сможете расширять / настраивать, где это необходимо. Это еще одна реальная проблема, преждевременная оптимизация.