数据建模的一种常用方法是使用数据建模工具（例如Erwin）生成模式，然后使用对象关系映射器（ORM）从模式生成业务对象。
不太常见的是使用业务对象（例如POCO / POJO）完成数据建模的逆向过程，使用ORM从该对象生成模式。
这个问题涉及包含数百个数据库表的非平凡系统。
我的印象是许多设计师/架构师因为一些隐藏的问题而远离第二种方法，例如模式修订之间的数据迁移，减少了对设计和调优SQL查询的控制。什么是真正的问题？
答案 0 :(得分：1)
对我来说，真正的问题通常是这句话：
“这个问题与...有关 包含的非平凡系统 数百个数据库表。“
增加了不必要的复杂性。无论你提到的方法是什么，都会发生这种情况，但这通常是真实问题的主要部分。
请注意，如果您的“系统包含hundren的数据库表”，则不应该讨论单个系统/上下文，而应该是一组应用程序/上下文。无论最后你最终将它放在同一个数据库中，复杂性都是通过不像一个巨大的东西建模到一个巨大的数据库来解决的。有限的背景是当今的流行词。
从POCO开始并不意味着你不能在必要时进行扩展/调整。这是另一个真正的问题，即过早优化。