我只是在这里看书:http://www.amazon.com/Java-Architects-Handbook-Second-Edition/dp/0972954880/试图找到有关如何有效设计(通用)中型到大型应用程序(200 个表或更多)的策略 - 例如经典的多层企业内部网。我正在尝试调整我过去的经验(作为数据库设计师，还有 OOAD)以构建这样的 Java 应用程序。根据我的阅读，如果您首先定义实体，则没有推荐的方法直接(自动)推断您的数据库。 该书说您将首先构建实体/对象模型 (OOAD)，然后是 db admin/dev.(?) 作业来基于已构建的实体模型构建/推断数据库(模式、规范化等) .如果是这种情况，恐怕架构师/开发人员可能会失去对重要方面的控制 - 规范化、实体-属性-值建模等。
也许像许多年长的开发人员(后端开发人员、架构师等)一样，我觉得首先定义数据库模式更舒服——然后花大量时间在规范化等方面。虽然现在这肯定是可能的，但我我问自己这是否会成为(如果还没有的话，很快)“老式方式”而不是规范 - 作为从头开始设计应用程序时的经典/推荐方法。
我知道 Entity Framework (.NET) 已经明确定义了这些方法——“实体优先”、“数据库优先”、“代码优先”，如果需要，这些方法可以混合使用。我当然知道他们建议新设计的应用程序“实体优先”，如果您已经定义了数据库架构，则建议“数据库优先”(许多旧应用程序就是这种情况，在迁移等时。我只是问是否有什么东西与 Java 世界类似。
所以，问题是:(虽然我知道没有 Elixir 等)
- 新建应用程序的“实体优先”——这是当今的常态吗？
- 您使用什么工具(如果有)来帮助推断数据库架构过程？ - 您对具体 UML 的经验、优缺点 工具等
- 如果您有部分/较旧/子域数据库模式(主要是您想要保留的)怎么办？在这种情况下，您可以从中推断实体模型 数据库，然后使用您首选的 UML 工具重构模型？
- 从劳动力的角度来看(比如 200-500 个表的数据库):什么是最好的方法:例如，让 2 个不同的人 分别参与设计OOAD/实体和数据库， 与建筑师一起工作？
最佳答案
如您所料 - 我的回答是视情况而定。
问题在于，一个好的设计有太多可能的风格和维度，您真的需要首先考虑尽可能广泛的观点。
问自己一些重要的问题:
系统的核心在哪里？ 数据库真的是核心还是它实际上只是代码的持久层。也可能是数据库是核心，而代码实际上只是数据上的时髦 UI。也可以混合使用 - 其中一些表是核心以及一些实体。
您对 future 有什么看法？请记住，就在我们说话的时候，数据库技术正在迅速向前发展。有一些数据库都是在内存中的。有些是为分布式架构设计的。有些主要是云。如果您首先构建自己的模式，您就有可能将自己锁定在某种技术上。
您想达到什么规模？如果坚持使用特定的数据库，您可能会关闭手持设备的大门。
我通常发现实体优先 是最好的初始方法，因为您总是可以从实体和一些元数据中派生出模式。肯定可以先架构并从架构中扩展实体，但您通常会发现数据库对设计的影响太大。
关于java - 从头开始设计 Java 应用程序时总是 'Entity first' 方法？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31584343/