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