类设计与数据库设计（ER图）

Question

类设计与数据库设计（ER图）

4

在系统开发的设计阶段，类设计应该主导数据库的设计，还是数据库设计应该主导类设计？我意识到有几种情况下，一方已经存在，需要围绕现有的设计另一方。但是，假设您可以从头开始，哪种方法更好？我倾向于先进行类设计，然后再进行数据库设计，但希望听取一些关于这个想法的意见。需要考虑哪些扩展问题？实施问题？

- Chad Harrison

4个回答

2

我认为这取决于应用程序的性质。如果您的应用程序主要关注数据方面，那么您应该优先考虑数据库而不是应用程序设计；如果您的应用程序主要是业务逻辑或计算方面，那么您可能想优先考虑应用程序设计。

另一个考虑因素是应用程序的长期性和覆盖范围 - 正如Jay所说，多个应用程序使用同一个数据库并不罕见。但我实际上建议为数据库提供基于服务或消息的接口 - 我认为您不希望允许多个应用程序直接访问数据。在这种情况下，我认为您会在服务层方面非常重视设计工作。

您还可以考虑将设计映射到业务领域 - 理想情况下，您希望您的软件反映业务概念（请查看Evans的“领域驱动设计”）。通常情况下，使用对象技术而不是实体关系模型（经典问题是如何将继承映射到数据库模型）更容易实现此目标。

最后，重要的是考虑团队的技能和倾向 - 让一群数据库专家设计对象模型通常会导致陡峭的学习曲线（反之亦然）。

- Neville Kuyt

1

班级设计应该决定数据库的设计，还是数据库设计应该决定班级设计？

我不确定哪一个应该“决定”另一个的设计。 “决定”意味着紧密耦合，这通常是不好的事情。

数据库设计假定其他程序将访问数据库。数据库设计的重要部分是选择良好的表名，列名和完整性约束。所有这些都是数据库的公共接口的一部分。（所有这些也与规范化紧密相关，这是一种基于数学的过程，应用程序开发缺乏这方面的知识。这是一种观察，而不是批评。）

更改设计不良的公共接口真的非常昂贵。

- Mike Sherrill 'Cat Recall'

关于耦合的观点很好。我的意思是，如果你设计一个类去处理一些日期数据类型或者对象，那么一个能力强大的数据库也应该将其作为日期字段来处理，因为这个类就是为此而设计的。反之亦然，如果一个数据库被设计成接受日期字符串，那么类必须被设计成接受字符串并尝试进行日期转换。 - Chad Harrison

@hydroparadise 大多数应用程序都会有一个单独的层，处理从应用程序语言中数据类型的表示到其在数据库中的表示的转换。这使得应用程序和数据库可以使用最自然的数据类型。PHP 有 Doctrine 来帮助实现这样的映射，Java 有 Hibernate。 - Matt Wonlaw

1

你的数据库应该经过深思熟虑，但是应用程序和数据库设计都不应该对彼此产生重大影响。你的应用程序应该是数据库无关的。为了存储应用程序数据，你应该依赖于一个提供必要的翻译从你的领域对象到数据库表的层。

- Matt Wonlaw

所以让我来澄清一下，假设一个应用程序据称连接Ms Sql Server和Oracle，那么每个连接都应该有一个单独的层与Db和应用程序进行交互？这些层是作为框架工具提供的（根据您之前对Catcall答案的评论所收集的信息），还是通常是开发的组件，因为可能存在多种实现组合？ - Chad Harrison

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jay · Accepted Answer

每当我开始一个项目时，几乎总是从数据库设计开始。如果你的程序有错误或设计不良，最坏情况下可以丢掉那个程序并重新编写。但如果你的数据库存在错误或设计不良，等你意识到问题时可能已经有数百个程序在使用该数据库。更改数据库意味着至少要研究使用它的每个程序，并且重大的数据库设计更改可能意味着需要大量修改使用该数据库的每个程序。因此，对于你的数据库来说，拥有良好的设计比拥有良好的程序更为重要。