从头开始设计 java 应用程序时总是 'Entity first' 方法？
Always 'Entity first' approach, when designing java apps from scratch?
我只是在这里读这本书：http://www.amazon.com/Java-Architects-Handbook-Second-Edition/dp/0972954880/ 试图找到一种策略来有效地设计（通用）中型到大型应用程序（200 个表或更多）——例如经典的多表分层的企业内部网。我正在尝试调整我过去的经验（作为数据库设计者，还有 OOAD）以构建这样一个 java 应用程序。根据我的阅读，如果您首先定义实体，则没有推荐的方法直接（自动）推断您的数据库。
这本书说你会首先构建 entity/object 模型 (OOAD)，然后是 db admin/dev.(?) 作业到 build/infer 基于数据库（模式、规范化等）在已经构建的实体模型上。如果真是这样，恐怕 architect/developer 可能会失去对重要方面的控制 - 规范化、实体属性值建模等
也许像许多年长的开发人员（后端开发人员、架构师等）一样，我觉得首先定义数据库模式更舒服 - 并在规范化等方面花费大量时间。虽然现在这肯定是可能的，我问自己这是否会成为（很快，如果还没有的话）'old fashioned way' 而不是规范 - 作为从头开始设计应用程序时的 classic/recommended 方法。
我知道 Entity Framework (.NET) 已经明确定义了这些方法 - 'entities first'、'database first'、'code first' 并且如果需要，可以混合使用这些方法。我当然知道他们推荐 'entity first' 用于新设计的应用程序，并且 'database first' 如果您已经定义了数据库模式（许多旧应用程序就是这种情况，在迁移时等。我只是问是否有与 java 世界类似。
所以，问题是：（虽然我知道没有灵丹妙药等）
- 'Entities first' 用于新建应用程序 - 这是现在的常态吗？
- 您使用什么工具（如果有的话）来帮助推断数据库架构过程？ - 您对具体 UML 的经验、优缺点
工具等
- 如果您有 parts/older/sub-domain 数据库模式（主要是您想要保留的）怎么办？在这种情况下，您可以从中推断实体模型
数据库，然后使用您喜欢的 UML 工具重构模型？
- 从劳动力的角度来看（比如 200-500 个表的数据库）：什么是最好的方法：例如，有 2 个不同的人
分别参与设计OOAD/entities和数据库，
与建筑师合作？
如您所料 - 我的回答是这取决于。
问题在于，一个好的设计有太多可能的风格和维度，您真的需要首先考虑最广泛的观点。
问自己一些重要问题：
系统的核心在哪里？数据库真的是核心还是只是代码的持久层。也可能是数据库是核心，而代码实际上只是对数据的时髦 UI。也可以混合使用 - 其中 some 表是核心以及 some 实体。
您对未来有什么看法？请记住，就在我们说话的时候，数据库技术正在迅速向前发展。有一些数据库都是在内存中的。有些是为分布式架构设计的。有些主要是云。如果您首先构建您的架构，您可能会冒着将自己锁定在某种技术上的风险。
您想达到什么规模？如果坚持使用特定的数据库，您可能会关闭手持设备的大门。
我通常发现 实体优先 是最好的初始方法，因为您始终可以从实体和一些元数据中派生出模式。当然可以先 架构 并从架构中扩展实体，但通常您会发现数据库对设计的影响太大。
1) 我过去先做数据库，但现在我通常先做实体，但这主要是因为我在创建应用程序时使用的工具。与稍后尝试将您的实体与您定义的架构相匹配相比，实体优先有一些很好的优势。您也没有将自己紧紧锁定在您的架构上。您的应用程序的用途也很重要，如果它只是一个基本的 CRUD 应用程序，一次编写多次阅读或实际执行 'do' 一些可以让您选择如何构建应用程序的东西。
2) 我经常使用 hibernate，它鼓励首先创建模型，设计所有实体等，然后从中生成模式，hibernate 可以从您创建的模型生成整个模式（尽管您可能需要调整它们以确保它们不疯狂）。如果您的模型中有 200 个实体，那么您可能希望提前进行大量 UML 建模以确保您的模型是一致的。
3) 如果您使用的是部分遗留数据库，那么有时最好符合该数据库的架构设计，这样您的实体和架构就可以保持一致。这可能有点痛苦，但它试图解释为什么你的应用程序的一部分与其他部分不同。所以是的，在这种情况下，我可能会从模式中推断出我的实体。但同样，如果这完全是疯狂的，那么它可能是做一些非常具体的 DAO 代码来从那个应用程序中隐藏那部分模式并假装它不存在。
4) 我真的不能给你一个很好的答案，因为我不确定你到底在做什么。一旦你有了模式的设计标准，它就会转动手柄来启动它。
毕竟我的答案是 'It depends'
虽然已经发布的答案涵盖了很多要点 - 最终，所有答案可能都必须总结为 "it depends" - 我想扩展已经触及的一点。
我的重点是数据 - 我是一名商业智能和数据仓库开发人员，我处理数据质量、数据治理、拥有一组主数据等问题。为此，我必须从其他系统中提取数据 - 处于不同条件下的数据。
在考虑系统的核心是数据库还是前端时（如 OldCurmudgeon 所建议的），我强烈建议跳出您自己的领域进行思考。我已经看到和听说过许多系统，其中很明显数据库已被视为事后才想到（有时通过实体优先模型创建，但有时手工构建），尽管大部分业务价值都在数据。越来越多的公司当然意识到他们的数据是有价值的，并正在采用工具来利用它——但如果糟糕的交易数据库意味着数据已经丢失、一开始就没有保存、被覆盖，这就很难做到了当需要历史或不一致时。
虽然我不想让我自己和其他担任类似角色的人失业：如果您正在处理的系统的数据有价值或可能有价值，如果有任何理由可能被访问除了您正在创建的前端之外的任何东西，那么值得花时间和精力来创建一个合理的数据模型来保存它。如果系统是为一个组织使用的或将要出售给组织，他们很有可能会想要从中报告，并希望 运行 从它输出到数据仓库或其他数据存储中，并希望对其创建和保存的数据进行分析。
我对像 Hibernate 这样的工具知之甚少，不知道是否有可能既使用它们以实体优先的方式工作，又创建一个高质量的数据库，但我知道我遇到了一些问题以这种方式创建的数据库。至少，正如所建议的那样，如果您要以这种方式工作，请确保它正在产生一些理智的东西，并可能在必要时进行调整以保持数据完整性。如果数据完整性是一项关键要求，并且您无法获得这样的工具来创建合适的数据库来确保数据完整性，那么也许可以考虑返回到 "old fashioned" 方式来做事。
我还建议开发人员与任何数据专家、分析师、架构师等一起工作具有真正的价值。他们可能作为同事进行一些前期建模，即使他们随后生成的系统使用实体-首先，即使由于技术原因它偏离了早期生产的更具概念性的模型。我见过许多系统中的固有问题，这些问题是由于对更广泛的业务实体和关系缺乏了解而导致的，如果花时间以这种方式了解整体结构，这些问题本可以避免。当我自己还是一名应用程序开发人员时，我亲自负责 构建 这些问题，所以这不应被理解为对前端开发人员的批评 - 只是投赞成票- 在决定开发方法和设计之前进行功能和协作分析和建模。
我只是在这里读这本书：http://www.amazon.com/Java-Architects-Handbook-Second-Edition/dp/0972954880/ 试图找到一种策略来有效地设计（通用）中型到大型应用程序（200 个表或更多）——例如经典的多表分层的企业内部网。我正在尝试调整我过去的经验（作为数据库设计者，还有 OOAD）以构建这样一个 java 应用程序。根据我的阅读，如果您首先定义实体，则没有推荐的方法直接（自动）推断您的数据库。 这本书说你会首先构建 entity/object 模型 (OOAD)，然后是 db admin/dev.(?) 作业到 build/infer 基于数据库（模式、规范化等）在已经构建的实体模型上。如果真是这样，恐怕 architect/developer 可能会失去对重要方面的控制 - 规范化、实体属性值建模等
也许像许多年长的开发人员（后端开发人员、架构师等）一样，我觉得首先定义数据库模式更舒服 - 并在规范化等方面花费大量时间。虽然现在这肯定是可能的，我问自己这是否会成为（很快，如果还没有的话）'old fashioned way' 而不是规范 - 作为从头开始设计应用程序时的 classic/recommended 方法。
我知道 Entity Framework (.NET) 已经明确定义了这些方法 - 'entities first'、'database first'、'code first' 并且如果需要，可以混合使用这些方法。我当然知道他们推荐 'entity first' 用于新设计的应用程序，并且 'database first' 如果您已经定义了数据库模式（许多旧应用程序就是这种情况，在迁移时等。我只是问是否有与 java 世界类似。
所以，问题是：（虽然我知道没有灵丹妙药等）
- 'Entities first' 用于新建应用程序 - 这是现在的常态吗？
- 您使用什么工具（如果有的话）来帮助推断数据库架构过程？ - 您对具体 UML 的经验、优缺点 工具等
- 如果您有 parts/older/sub-domain 数据库模式（主要是您想要保留的）怎么办？在这种情况下，您可以从中推断实体模型 数据库，然后使用您喜欢的 UML 工具重构模型？
- 从劳动力的角度来看（比如 200-500 个表的数据库）：什么是最好的方法：例如，有 2 个不同的人 分别参与设计OOAD/entities和数据库， 与建筑师合作？
如您所料 - 我的回答是这取决于。
问题在于，一个好的设计有太多可能的风格和维度，您真的需要首先考虑最广泛的观点。
问自己一些重要问题：
系统的核心在哪里？数据库真的是核心还是只是代码的持久层。也可能是数据库是核心，而代码实际上只是对数据的时髦 UI。也可以混合使用 - 其中 some 表是核心以及 some 实体。
您对未来有什么看法？请记住，就在我们说话的时候，数据库技术正在迅速向前发展。有一些数据库都是在内存中的。有些是为分布式架构设计的。有些主要是云。如果您首先构建您的架构，您可能会冒着将自己锁定在某种技术上的风险。
您想达到什么规模？如果坚持使用特定的数据库，您可能会关闭手持设备的大门。
我通常发现 实体优先 是最好的初始方法，因为您始终可以从实体和一些元数据中派生出模式。当然可以先 架构 并从架构中扩展实体，但通常您会发现数据库对设计的影响太大。
1) 我过去先做数据库，但现在我通常先做实体，但这主要是因为我在创建应用程序时使用的工具。与稍后尝试将您的实体与您定义的架构相匹配相比，实体优先有一些很好的优势。您也没有将自己紧紧锁定在您的架构上。您的应用程序的用途也很重要，如果它只是一个基本的 CRUD 应用程序，一次编写多次阅读或实际执行 'do' 一些可以让您选择如何构建应用程序的东西。
2) 我经常使用 hibernate，它鼓励首先创建模型，设计所有实体等，然后从中生成模式，hibernate 可以从您创建的模型生成整个模式（尽管您可能需要调整它们以确保它们不疯狂）。如果您的模型中有 200 个实体，那么您可能希望提前进行大量 UML 建模以确保您的模型是一致的。
3) 如果您使用的是部分遗留数据库，那么有时最好符合该数据库的架构设计，这样您的实体和架构就可以保持一致。这可能有点痛苦，但它试图解释为什么你的应用程序的一部分与其他部分不同。所以是的，在这种情况下，我可能会从模式中推断出我的实体。但同样，如果这完全是疯狂的，那么它可能是做一些非常具体的 DAO 代码来从那个应用程序中隐藏那部分模式并假装它不存在。
4) 我真的不能给你一个很好的答案，因为我不确定你到底在做什么。一旦你有了模式的设计标准，它就会转动手柄来启动它。
毕竟我的答案是 'It depends'
虽然已经发布的答案涵盖了很多要点 - 最终，所有答案可能都必须总结为 "it depends" - 我想扩展已经触及的一点。
我的重点是数据 - 我是一名商业智能和数据仓库开发人员，我处理数据质量、数据治理、拥有一组主数据等问题。为此，我必须从其他系统中提取数据 - 处于不同条件下的数据。
在考虑系统的核心是数据库还是前端时（如 OldCurmudgeon 所建议的），我强烈建议跳出您自己的领域进行思考。我已经看到和听说过许多系统，其中很明显数据库已被视为事后才想到（有时通过实体优先模型创建，但有时手工构建），尽管大部分业务价值都在数据。越来越多的公司当然意识到他们的数据是有价值的，并正在采用工具来利用它——但如果糟糕的交易数据库意味着数据已经丢失、一开始就没有保存、被覆盖，这就很难做到了当需要历史或不一致时。
虽然我不想让我自己和其他担任类似角色的人失业：如果您正在处理的系统的数据有价值或可能有价值，如果有任何理由可能被访问除了您正在创建的前端之外的任何东西，那么值得花时间和精力来创建一个合理的数据模型来保存它。如果系统是为一个组织使用的或将要出售给组织，他们很有可能会想要从中报告，并希望 运行 从它输出到数据仓库或其他数据存储中，并希望对其创建和保存的数据进行分析。
我对像 Hibernate 这样的工具知之甚少，不知道是否有可能既使用它们以实体优先的方式工作，又创建一个高质量的数据库，但我知道我遇到了一些问题以这种方式创建的数据库。至少，正如所建议的那样，如果您要以这种方式工作，请确保它正在产生一些理智的东西，并可能在必要时进行调整以保持数据完整性。如果数据完整性是一项关键要求，并且您无法获得这样的工具来创建合适的数据库来确保数据完整性，那么也许可以考虑返回到 "old fashioned" 方式来做事。
我还建议开发人员与任何数据专家、分析师、架构师等一起工作具有真正的价值。他们可能作为同事进行一些前期建模，即使他们随后生成的系统使用实体-首先，即使由于技术原因它偏离了早期生产的更具概念性的模型。我见过许多系统中的固有问题，这些问题是由于对更广泛的业务实体和关系缺乏了解而导致的，如果花时间以这种方式了解整体结构，这些问题本可以避免。当我自己还是一名应用程序开发人员时，我亲自负责 构建 这些问题，所以这不应被理解为对前端开发人员的批评 - 只是投赞成票- 在决定开发方法和设计之前进行功能和协作分析和建模。