我只是在这里阅读这本书：http://www.amazon.com/Java-Architects-Handbook-Second-Edition/dp/0972954880/试图找到一个关于如何有效地设计（通用）中型到大型应用程序（200个表或更多）的策略 - 例如经典的，多层的，企业内联网。我正在尝试调整我过去的经验（作为数据库设计师，还有OOAD）以构建这样的Java应用程序。根据我的阅读，如果您首先定义实体，则不建议直接（自动）推断数据库。 书中说你将首先构建实体/对象模型（OOAD），然后根据已经构建的实体模型构建/推断数据库（模式，规范化等）的db admin / dev。（？）作业。如果是这种情况，我担心架构师/开发人员可能会失去对重要方面的控制 - 规范化，实体 - 属性 - 价值建模等。
也许像许多老开发人员（后端开发人员，架构师等）一样，我觉得首先定义数据库架构会更加自如，并且在规范化等方面花费大量时间。虽然现在肯定可以实现，但我我问自己这是否会成为（很快，如果还没有）“老式的方式”而不是常态 - 作为从头开始设计应用程序时的经典/推荐方法。
我知道实体框架（.NET）已经明确定义了这些方法 - “实体优先”，“数据库优先”，“代码优先”，如果需要，这些可以混合使用。我肯定知道他们建议'实体优先'用于新设计的应用程序，并且'数据库优先'如果你已经定义了数据库模式（许多旧应用程序的情况，迁移时等等）我只是问是否有什么东西类似于java世界。
所以，问题是:(虽然我知道没有银弹等。）
答案 0 :(得分：4)
如您所料 - 我的回答是取决于。
问题在于，良好的设计有很多可能的风格和尺寸，你需要首先采用最广泛的视图。
问自己一些重大问题：
系统的核心在哪里？数据库真的是核心，还是实际上只是代码的持久层。它也许也可能是数据库是核心，而代码实际上只是数据的时髦UI。还可以有一个混合 - 其中某些表是核心以及某些实体。
您对未来的看法是什么？请记住，正如我们所说的那样，正在发展，正在迅速推动数据库技术的发展。有些数据库都在内部。有些是为分布式架构而设计的。有些主要是云。如果您首先构建架构，则可能会将自己锁定在特定技术中。
您希望达到什么规模？通过坚持特定的数据库，您可能会关闭可能手持的存在。
我通常认为 entity first 是最好的初始方法，因为您总是可以从实体和一些元数据中派生出一个模式。当然可以首先使用模式并将实体扩展到模式之外，但通常情况下，您通常会发现数据库对设计的影响太大。
答案 1 :(得分：2)
1）我过去曾经做过数据库，但现在我通常先做实体，但这主要是因为我在创建应用程序时使用的工具。实体首先比稍后尝试将您的实体与您定义的模式匹配有一些好处。您还没有将自己锁定在您的架构上。如果它只是一个基本的CRUD应用程序，那么你的应用程序的用途很多，如果只读了很多，那么它实际上是做什么的。能帮助您选择如何构建应用程序的东西。
2）我使用hibernate，鼓励首先创建模型，设计所有实体等，然后从中生成模式，hibernate可以从你创建的模型生成整个模式（尽管你可能需要）调整它们以确保它们不会疯狂）。如果模型中有200个实体，那么您可能希望提前进行大量的UML建模，以确保模型的一致性。
3）如果您正在使用部分遗留数据库，那么有时可以很好地与模式设计保持一致，这样您的实体和模式就是一致的。它可能有点痛苦但是它试图解释为什么你的应用程序的一部分与其他部分不同。所以是的，我可能会在这种情况下从模式中推断出我的实体。但是，如果它完全疯了，那么可能会做一些非常具体的DAO代码来隐藏该应用程序中的那部分模式，并假装它不在那里。
4）我不能真正给你一个很好的答案，因为我不确定你真正开车的是什么。一旦你有了你的架构的设计标准，它就会转动手柄来解决它。
毕竟，我的答案是＆＃39;它取决于＆＃39;
答案 2 :(得分：2)
虽然已经发布的答案涵盖了许多要点 - 最终，所有答案可能都要总结为“它取决于” - 我想扩大已经触及的一点。
我的重点是数据 - 我是商业智能和数据仓库开发人员，我处理数据质量，数据治理，拥有一组主数据等问题。为此，我必须提取数据来自其他系统 - 处于不同条件下的数据。
在考虑你的系统的核心是真的是数据库还是前端时（正如OldCurmudgeon所建议的那样），我强烈建议你在自己的领域之外思考。我已经看到和听说过许多系统，很明显数据库已被视为事后的想法（有时是通过实体优先模型创建的，有时也是手工构建的），尽管事实上大多数商业价值都在数据。越来越多的公司当然意识到他们的数据是有价值的，并且正在采用工具来利用它 - 但如果糟糕的交易数据库意味着数据丢失，从未保存过，那么很难做到被覆盖当需要历史或不一致时。
虽然我不想做自己和其他具有类似职责的人从事工作：如果您正在处理的系统的数据是或可能是有价值的，如果有任何原因可能被任何其他人访问而不是你正在创造的前端，那么创造一个声音数据模型来保持它是值得的。如果系统是针对某个组织的，或者是要出售给组织的，那么他们就有可能想要报告它，想要将输出从它运行到数据仓库或其他数据存储中，并希望对其创建和保留的数据进行分析。
我不太了解像Hibernate这样的工具，知道是否可以使用它们以实体优先的方式工作并仍然创建一个高质量的数据库，但我知道我遇到了一些有问题的数据库创建以这种方式。至少，正如已经建议的那样，如果你打算以这种方式工作，请确保它能够产生一些理智的东西，并在必要时调整它以保持数据的完整性。如果数据完整性是一个关键要求，并且您无法使用这样的工具来创建一个能够确保数据完整性的合适数据库，那么可以考虑以“老式”的方式回归。
我还建议，与任何数据专家，分析师，架构师等一起工作的开发人员都有真正的价值，他们可能作为同事进行一些前期建模，即使他们当时生产的系统使用实体优先和即使它偏离了早期因技术原因而产生的概念模型。我已经看到系统中出现了许多问题，这些问题是由于对更广泛的业务实体和关系缺乏了解造成的，如果花费时间用这种方式来理解整体结构，那么本来可以避免这些问题。当我自己是一名应用程序开发人员时，我个人负责构建这些问题，所以这不应该被视为对前端开发人员的批评 - 只是投票支持跨职能和在确定开发方法和设计之前进行协作分析和建模。