Sql 使用业务对象建模数据时隐藏的问题

数据建模的一种常见方法是使用数据建模工具（如Erwin）生成模式，然后使用对象关系映射器（ORM）从模式生成业务对象

不太常见的是使用业务对象（例如POCO/POJO）进行数据建模的反向过程，从中使用ORM生成模式

这个问题是针对包含数百个数据库表的非平凡系统提出的

---

我的印象是，许多设计师/架构师由于一些隐藏的问题而远离第二种方法，例如模式修订之间的数据迁移，减少了对设计和调优SQL查询的控制。真正的问题是什么？

对我来说，真正的问题通常是这句话：

“这个问题是关于 包含以下内容的非平凡系统： 数百个数据库表。”

增加了不必要的复杂性。不管你提到什么方法，这种情况都会发生，但这通常是真正问题的主要部分

请注意，如果您有一个“由数百个数据库表组成的系统”，那么您不应该谈论单个系统/上下文，而是一组应用程序/上下文。不管最终是否将其放在同一个数据库中，复杂度的解决方法是不将其建模为一个巨大的事物，而是将其全部放在一个巨大的数据库中。有界语境是当今的流行语

---

从POCO开始并不意味着以后不能在必要的地方进行扩展/调优。这是另一个真正的问题，即过早优化。

在我对后者有限的经验中，我始终发现缺少定义的外键关系是非常令人不安的。哦，请再重复一次愚蠢的过早优化。数据库设计需要在构建之前考虑优化，因为数据库比应用程序代码更难重构。应该从一开始就避免性能较差的代码（通过使用通常性能较差的代码）。性能对于数据库来说至关重要，而不是事后诸葛亮，如果您想要一个性能良好的数据库，那么在设计时就必须考虑性能。过早优化是为了避免寻找那一点点，而不是为了避免在设计中考虑优化。@HLGEM好的，我向你挑战，我在哪里说过必须没有系统的设计？在设计/编码系统时不应该考虑性能？您不应该为给定场景构建合理的代码。。。当您需要大量额外的DB功能来对其进行微调时，当您更好地处理您所指的代码/设计时，即在性能上会产生X级差异而不仅仅是10-30%的代码/设计时，这是过早的优化。y，我明白，对于一个每天有1亿多人登录的系统来说，它是不同的…似乎是有意义的，1999年大学编程课的第一天，一位老师告诉我的“分而治之”，简单的陈述很容易应用，很难想象，但有经验。当然，这一切都是在良好的设计和架构的背景下进行的。