3

我只是在这里读这本书：http: //www.amazon.com/Java-Architects-Handbook-Second-Edition/dp/0972954880/ 试图找到一种策略来有效地设计一个（通用）中型到大型应用程序（200 个表或更多）——例如一个经典的、多层的、企业内部网。我正在尝试调整我过去的经验（作为数据库设计师，但也是 OOAD），以便构建这样一个 java 应用程序。根据我的阅读，如果您先定义实体，则不推荐直接（自动）推断数据库的方法。这本书说您将首先构建实体/对象模型（OOAD），然后有 db admin/dev.(?) 作业基于已构建的实体模型构建/推断数据库（模式、规范化等） . 如果是这种情况，恐怕架构师/开发人员可能会失去对重要方面的控制——规范化、实体属性值建模等。

也许像许多年长的开发人员（后端开发人员、架构师等）一样，我觉得首先定义数据库模式更自在 - 并在规范化等方面花费大量时间。虽然现在这肯定是可能的，但我问自己如果这将成为（很快，如果还没有的话）“老式方式”而不是规范 - 作为从头开始设计应用程序时的经典/推荐方法。

我知道 Entity Framework (.NET) 已经明确定义了这些方法——“实体优先”、“数据库优先”、“代码优先”，如有必要，这些方法可以混合使用。我当然知道他们为新设计的应用程序推荐“实体优先”，如果您已经定义了数据库模式（对于许多旧应用程序，迁移等时都是这种情况），则推荐“数据库优先”。我只是在问是否有什么类似的Java世界。

所以，问题是：（虽然我知道没有灵丹妙药等）

  1. 新建应用程序的“实体优先”——这是当今的常态吗？
  2. 您使用什么工具（如果有的话）来帮助推断数据库模式过程？- 您在具体 UML 工具等方面的经验、优缺点。
  3. 如果您有部分/旧/子域数据库模式（主要是您想要保留的）怎么办？在这种情况下，您会从数据库中推断实体模型，然后使用您首选的 UML 工具重构模型？
  4. 从劳动力的角度来看（假设数据库有 200-500 个表）：最好的方法是什么：例如，让 2 个不同的人分别参与设计 OOAD/实体和数据库，并与架构师一起工作？
4

3 回答 3

4

如您所料 - 我的回答是视情况而定。

问题是一个好的设计有很多可能的风格和维度，你真的需要首先尽可能广泛地观察。

问自己一些大问题：

系统的核心在哪里？数据库真的是核心还是它实际上只是代码的持久层。也可能是数据库是核心，而代码实际上只是数据上的一个时髦的 UI。也可以是混合的——其中一些表与一些实体一起是核心。

你对未来有什么看法？请记住，正如我们所说的那样，数据库技术正在迅速向前发展。有一些数据库都在内存中。有些是为分布式架构设计的。有些主要是云。如果您首先构建您的模式，您可能会将自己锁定在某种技术中。

你想达到什么规模？通过坚持使用特定的数据库，您可能会关闭手持设备的大门。

我通常认为实体优先是最好的初始方法，因为您总是可以从实体和一些元数据中派生模式。当然可以先使用模式并从模式中扩展实体，但这样您通常会发现数据库对设计的影响太大。

于 2015-07-23T10:26:08.043 回答
2

1）我过去先做数据库，但现在我通常先做实体，但这主要是因为我在创建应用程序时使用的工具。与稍后尝试将实体匹配到定义的模式相比，实体首先具有一些很好的优势。您也没有将自己锁定在您的架构中。您的应用程序的用途也很重要，如果它只是一个基本的 CRUD 应用程序，请编写一次阅读多次，或者它实际上是否“做”一些事情，这将告知您如何构建应用程序的选择。

2）我经常使用hibernate，它鼓励首先创建模型，设计所有实体等，然后从中生成模式，hibernate可以从你创建的模型中生成整个模式（尽管你可能需要调整它们以使确保他们没有疯）。如果您的模型中有 200 个实体，那么您可能需要提前进行大量 UML 建模以确保您的模型是一致的。

3）如果您使用部分遗留数据库，那么有时最好符合架构设计，以便您的实体和架构保持一致。这可能有点痛苦，但它试图解释为什么你的应用程序的一部分与其他部分不同。所以是的，在这种情况下，我可能会从模式中推断出我的实体。但是，如果这完全是疯狂的，那么它可能是做一些非常具体的 DAO 代码来隐藏该应用程序的那部分架构并假装它不存在。

4）我真的不能给你一个很好的答案，因为我不确定你到底在做什么。一旦你有了你的模式的设计标准，它就会转动把手来把它弄出来。

所以毕竟我的答案是“这取决于”

于 2015-07-23T10:37:56.137 回答
2

虽然已经发布的答案涵盖了很多要点 - 最终，所有答案可能都必须总结为“它取决于” - 我想扩展已经触及的一点。

我的重点是数据——我是一名商业智能和数据仓库开发人员，我处理数据质量、数据治理、拥有一组主数据等问题。为此，我必须从其他系统中提取数据- 处于不同条件下的数据。

在考虑您系统的核心是真正的数据库还是前端时（如 OldCurmudgeon 所建议的），我强烈建议您跳出自己的领域思考。我见过并听说过许多系统，其中很明显数据库被视为事后才考虑（有时通过实体优先模型创建，但有时也手动构建），尽管事实上大部分业务价值都在数据。越来越多的公司当然意识到他们的数据是有价值的，并且正在采用工具来利用它——但是如果糟糕的事务数据库意味着数据已经丢失、从一开始就没有保存、已经被覆盖，那就很难做到当需要历史记录或不一致时。

虽然我不想让自己和其他类似角色的人失业：如果您正在使用的系统的数据是有价值的或可能有价值，如果有任何理由可能会被前台以外的任何人访问结束你正在创建的，那么值得花时间和精力来创建一个健全的数据模型来保存它。如果该系统是为一个组织或将要出售给组织的，那么他们很有可能希望从中报告，希望将其输出运行到数据仓库或其他数据存储中，并且希望对其创建和保存的数据进行分析。

我对 Hibernate 之类的工具了解得不够多，不知道是否可以同时使用它们以实体优先的方式工作并仍然创建高质量的数据库，但我知道我遇到过一些以这种方式创建的有问题的数据库. 至少，正如建议的那样，如果您打算以这种方式工作，请确保它产生的东西是理智的，并可能在必要时对其进行调整以保持数据完整性。如果数据完整性是一个关键要求，并且您无法获得这样的工具来创建一个合适的数据库来确保数据完整性，那么也许可以考虑回到“老式”的方式做事。

我还建议开发人员与任何数据专家、分析师、架构师等一起工作，他们可能作为同事进行一些前期建模，即使他们随后生成的系统使用实体优先，即使它出于技术原因，偏离了早期产生的更多概念模型。我在系统中看到了许多由于对更广泛的业务实体和关系缺乏了解而导致的固有问题，如果花时间以这种方式了解整体结构，这些问题是可以避免的。我个人负责建造当我自己还是一名应用程序开发人员时，这些问题不应被解读为对前端开发人员的批评——只是在决定开发方法和设计之前投票支持跨功能和协作分析和建模。

于 2015-07-23T14:19:49.197 回答