哪个更重要？数据库设计还是编码？

Question

哪个更重要：数据库的设计？还是应用程序代码的设计？

有很多关于可重用代码的信息（来自Carl Franklin dnrtv.com，CSLA.net等等），但我没有看到太多关于数据库设计和它对应用程序生命的影响（特别是早期设计决策的糟糕程度会影响应用程序在其'生命'中的后期。

Answer 1

通常，数据库结构更重要，因为它提供了开发代码的结构框架。通常（和YMMV非常相似），在完成开发阶段后重构数据库结构比简单地重构依赖于稳定数据库的代码要困难得多。原因很简单;重构数据库结构通常会强制更改代码;相反的情况很少发生。

很简单，您的代码依赖于您的数据库，而不是数据库取决于您的代码。 （如果不是这种情况，您可能需要重新考虑您的设计。）

解决您的编辑问题;我认为很多关于这类问题的人写作/写博客往往来自事物的“编码”方面，这些类型的人倾向于认为数据库设计是微不足道的，而不是编写有趣的解决方案。从本质上讲，对于那些喜欢解决“棘手问题”（往往是博客更多人）的人来说，编码方面比基本设计问题更有趣。虽然基本的设计问题并不“性感”，但它们非常重要（数据库设计是一个非常重要的设计问题）。

Answer 2

简答：两者兼而有之。这条链与最薄弱的环节一样强大。

Answer 3

如果你对任何一个都不认真，那你就注定要失败。

Answer 4

您的数据库设计是最重要的。

我是一名程序员，我更喜欢代码，但是......如果搞砸数据库设计，你的代码将是一场噩梦。 您的代码没有机会！

即使你试图重构数据库设计，你也会有大量的代码工作，修复它们将是压倒性的。

这不是偏好，甚至不是偏好，它非常倾向于DB设计最重要。

编辑：即使你有一些键值对表，其中所有内容都被转储到其中，这仍然是基于业务需求的数据库设计。

Answer 5

解释Knuth -

  

使用一个更重要的是   高效的数据结构。不好   结构会减慢你的速度   申请不管你的   算法和良好的结构可以   甚至消除了确定的需要   算法

我认为这同样适用于DB。您最终构建了一个大规模链接的数据结构。如果你没有使用正确的方法，你的应用程序将会很慢，无论你投入多少诡计。

Answer 6

以这种方式看待它

1. 更改代码意味着更改代码
2. 更改数据库可能会强制您更改代码

因此，尽早让数据库尽可能稳定非常重要

Answer 7

在使用过令人震惊的数据库设计之前，我必须把我的帽子放在数据库（或数据模型/ ORM）设计环中。

与一些在公司/客户中了解问题区域的人员在一起，获取纸上所需的所有数据，按逻辑区域分组，然后您将开始形成一个数据模型，您可以将其转换为对象，数据库模式或.xsd等。每个数据项都有一个名称，一个类型，可能是字符串的最大长度，或者是某个最小或最大容量的集合或列表或映射。

在此之后是否先设计数据库，或者OO模型由您决定，但至少您已经努力获得一个理智的分区模型。

实际上在MVC设计中，我会将OO数据模型（Java / C＃中的类）分类为模型，并与数据库模式本身链接（当然还增加了瞬态和实用方法）。您的控制器 - 您的问题中的“编码” - 应该使用模型实际实现业务逻辑，由您通过DAO / ORM从数据库中提取的对象表示。

Answer 8

  

域模型应独立于持久性实现细节（尽管该技术确实对模型设置了一些约束） - http://www.infoq.com/articles/ddd-in-practice

您应该专注于域模型。使用像Hibernate / NHibernate这样的ORM技术，数据库将只是一个实现细节。

如果您正在进行.NET Web开发，您应阅读的书籍：

1. ASP.NET MVC Framework Preview（只有100页，会让你入门）
2. NHibernate in Action
3. Domain Driven Design and Development In Practice（不读它，但我愿意，它是免费的）
4. Refactoring: Improving the Design of Existing Code

Answer 9

两者都不重要，但......

错误的数据库设计可能使编写好的程序变得不可能。此外，您通常可以重写错误的代码，但如果数据库中有大量数据，您只需要忍受在设计阶段做出的错误决定。

Answer 10

根据我的经验（我已经参与修复数据库问题大约30年并处理了数百个不同的数据库），数据库性能中的许多问题都来自于重用代码的不适当尝试。函数比内联代码慢得多。重用一次插入一条记录的存储过程的游标比基于集合的代码要远，远，远（光年）慢。重用一个可以回收你需要的东西和其他十个字段的过程会浪费服务器和网络资源。当您只需要来自其中三个表的信息时，使用连接到十个表的现有视图会浪费服务器资源。数据库中的代码重用并不像其他地方那样好。这并不是说如果需要，代码不应该被重用。只是它永远不应该优先于性能。遗憾的是，数据库没有很好地重用代码。大多数数据库不是面向对象的，在设计或访问它们时面向对象的思维通常会导致设计不佳。

在您考虑代码重用之前，您需要拥有一个坚如磐石的规范化数据库设计。您需要考虑如何提取以及将数据插入数据库。一旦有许多用户和记录，您需要考虑这种工作的效果，因为此时重新设计基本数据库结构通常会变得过于昂贵和耗时。重构应用程序代码通常比基本数据库结构容易得多，并且通常情况下，数据库重构无法完成。如果您将表结构更改为从非规范化表转换为父子结构，因为您发现当前结构不符合您的需求，那么您最终可能会针对此表更改数百甚至数千个查询。这就是为什么花费大量时间进行数据库设计很重要的原因，由于时间/金钱的限制，您将无法在以后重新访问它。如果您将数据库视为房屋的基础，并将应用程序代码视为结构，您将会看到为什么这是真的。用它上面的结构改变基础比移动内壁要困难得多。数据库和访问它们的应用程序是一样的。

Answer 11

我不会试图复制到目前为止所做的许多好评。我也不会花时间确定所发表的可疑陈述。

但我会补充以下几点。

如果您和大多数人一样，那么您指的是RDBMS作为您问题中的数据库。 RDBMS本质上是一个从属。它侦听端口，并且有义务尝试为来自该端口的所有请求提供服务。它无法知道哪些请求只是愚蠢或不明智。因此，最完美设计的DB很容易被滥用到锁定服务器的程度。这意味着代码更重要。各地的DBA可以发现他们的头发是为了回应应用程序开发人员在他们管理的服务器上抛出的一些蠢事。

因此，我可以就此主题提供的最佳建议是确保由设计数据库的同一开发人员编写的API访问数据库。让一个家伙（或一个向同一个家伙报告的小组）负责确保为两者做出合理的设计决策。如果你是那个家伙，那么不要以牺牲另一个为代价来吝啬。设计您的API，以便可以透明地对API的客户端进行数据库的重构。

Answer 12

我认为你不能以你所描述的方式将两者分开。一个人会不可避免地影响另一个人。例如，易于维护且性能良好的可靠数据库设计意味着更少的代码更改。良好的架构代码和对用例的深刻理解将导致整洁和可维护的数据库架构。

为了我的钱，我会在一个可靠的业务层上花费更多，并建立我的数据库来支持它，但这是我的知识偏见。

Answer 13

从某种意义上说，你不能将两者分开：数据库设计是编码 - 它不是用过程语言编写的。

但是，我使用过设计不佳的程序软件的系统，而且我使用过设计糟糕的数据库模式的系统（架构？）。根据我的经验，由于升级和兼容性问题，修复模式要困难得多。我可以想象系统可能并非如此。

Answer 14

我可以看到我将要向上游游泳，但我非常偏向软件作为你问题的答案。

虽然您的软件可以适应弱模式，但如果您的软件功能失效，您的数据库可能无法帮助您。我有几个案例，我已经能够采用流行的前端应用程序并完全重建数据库而不会造成严重中断，因为用户没有直接看到数据库。 （如果软件是废话，那将不会是真的。）

所以我要说的是先注意与用户最接近的内容。

Answer 15

我们在4年内重新编写了3次网站。数据库没有改变。 （好吧，一点点）

Answer 16

两者都很重要，它是一种共生关系。

但如果你的数据库被顶起，那么没有多少好的代码可以让你的应用程序大放异彩。

但是，如果你的数据库真的很好，那么好的代码可以让它变得更好（但是糟糕的代码仍然会破坏它）。

Answer 17

两个

糟糕的数据库设计可能会破坏优秀的代码，而糟糕的代码可能会破坏优秀的数据库设计。

Answer 18

取决于您对...和产品要求的了解。

忽略任何一方，您的产品可能会遇到麻烦。

那就是说，我倾向于遵循DDD编码风格，我首先定义除数据库之外的所有内容。这让我更好地了解需要存储哪些数据。

然后，一旦完成，我就可以创建和调整我的数据库。

Answer 19

这取决于对您的业务有何重要意义。理想情况下，你也不应该做出改变，但如果必须，你也应该问自己这个问题：

  

您的应用程序是否处理数据，或者数据是否超出您的应用程序？

换句话说，如果您的应用程序的代码部分今天爆炸，但您的数据仍然存在，那么灾难会有多糟糕？如果您的回答是：

  

我总是可以编写代码来替换应用程序，但是没有数据，我们就注定了。

然后你最好确保你的数据是合理的，因为它可能比你今天写的任何代码都要长。这并不是说您不应该花费大量精力来编写可靠的代码库，但代码最终是瞬态的，而您的数据则不是。如果您遇到错误的代码，您可以重写，但如果您有错误的数据，它可能会产生更广泛的影响。

另一方面，如果数据确实只是为了确保您的代码运行良好，并且代码本身更重要（与上述方案相反），您应确保拥有良好的代码库，并在以后重新审视数据中的任何缺陷。

修改

在大多数企业应用程序中，数据更为重要。我过去一直致力于转换项目，其中代码已经过了很长时间，但是迁移延迟了很长时间（有时几十年），因为数据非常糟糕，以至于需要花费大量的时间来自行调整数据。可以迁移的健康点。

Answer 20

它们不是相互排斥的。两者都必须坚如磐石才有机会获得坚如磐石的解决方案。

Answer 21

我同意这两者都很关键，但是您可以在视图，函数，存储过程级别使用大量技术来弥补相当可怕的底层架构错误。另一方面，如果你的编码很糟糕，当然没有修复它，那么你在设计层面上做的事情并不多，无法解决这个问题。

Answer 22

如果您不确定自己在这两个领域的技能，那么请尽可能地将两者分开。最糟糕的情况是编写一个混乱的混乱，以后不能轻易纠正或维护。

Answer 23

这取决于你的观点。如果你是DBA，那么db，如果你是开发人员而不是代码。

我见过开发人员用“包”表完全滥用数据库，我看到DBA创建了一个很好的应用程序代码，如果你了解数据库的结构，那就没问题了。

Ergo，两者都非常重要，如果你只是经历过那个，那么你应该让有经验的人去看对方，或者提高自己缺乏的技能。

Answer 24

两者都很重要，但任何上游活动中的糟糕设计通常更难以纠正。例如，对功能规范的更改自然会产生更多的工作，然后在接口上进行一些改变。

对数据库进行任何有意义的更改通常也需要更改编码，因此我个人花费了更多时间来编写数据库设计决策然后编写决策（尽管我确信我不是唯一一个花了一个小时的人或两个试图找到一个完美的名字）。

Answer 25

两者都只是实施的一部分，当然，你花费了大量的前期时间 - 要求和设计。

Answer 26

数据库是对给定流程和系统进行建模的计算机程序的工件

理想情况下，它不应该引起任何关注

目前的对象持久性技术尚未完全存在，因此在未来一段时间内您可能会关注它

问题是：那里有什么数据库？

如果要在您的流程和系统模型中保留对象，那么您不应该与它有太多关系

如果要修复模型中的漏洞，那么您将花费大量时间在其上

Answer 27

恕我直言良好的数据库设计更重要的是良好的编码（良好的编码也很重要，但与数据库设计相比）。

1. 只是因为数据库会存储您宝贵的数据。
2. 错误的编码可能不会影响数据库，但会影响整个应用程序的可伸缩性，性能等。在一段时间内，这可以通过重构（当然涉及一些成本）来解决。
3. 重构数据库更加昂贵和困难。
4. 通常我们在同一个数据库上运行多个不同的应用程序，因此它是一个共同的因素。

Answer 28

也许，我在数据库设计方面不是很有经验，但我的感觉是：如果您的业务类设计得很好，那么访问数据库的唯一方法就是在您的存储库中（DDD）。

因此，数据库中的更改只是对存储库实施的更改。 糟糕的数据库设计会使您的存储库难以编码，并且执行速度很慢，但它不会影响您的业务层（90％的代码）。

如果您因DAO图层而尝试修改业务层，为什么不修改业务层，因为您的表示层？然后祝你好运，满足所有约束和良好做法！

我认为两者都很重要，但编码和数据库设计不应该在同一手中。 对于开发人员来说，更重要的是将自己与数据库设计师的工作区分开来。（即使Db设计人员和开发人员是同一个人，你也不必同时考虑两件事）

Answer 29

取决于您当然喜欢什么，但未来是抽象数据层 - 也就是说，将数据存储视为一个实现细节，而不是应用程序的核心。

你会在某些圈子里听到“持久性无知”这个词。目标是在不知道数据如何存储的情况下设计域模型（业务实体）。在幕后，它可能是SQL，AmazonDB或XML。

如果你喜欢DBA的东西，那就是你应该去的地方。但是如果你想在应用程序方面更多，那就去了解ORM框架。

Answer 30

设计你是否是DBM。

编码，如果你是一名程序员。

这些并不是相互排斥的，应该都能很好地执行。

Answer 31

这是推理数据与可执行代码根本不同的错误。细胞自动机理论充满了例子，数据和代码都被强烈“复杂化”。

但是，因为一旦选择BD不太容易修改，你应该关注全局架构。但是如果你不确定最后一个，那么你应该尽量考虑最容易消耗的BD架构。

我的经验表明，修改代码比使用BD更容易。

Answer 32

我不能说数据库设计比代码设计更重要但它至少是相同的。如果您编写了很棒的代码，但是您的数据库很糟糕，那么您的应用程序将遇到性能问题，反之亦然。

DB设计有很多关于它的材料（包括书籍）。看看database normalization

的主题

Answer 33

"Apps are temporary, but data is permanent"

对我来说，数据库设计更重要，它是您要编写代码的应用程序的基础。

Answer 34

准确和专业地做到这一点非常重要。为了避免将来头疼，现在就做好了，因为当事情陷入困境时，改变，修复或改进会更加困难。

Answer 35

数据库的设计以及代码与数据的交互方式将对您的性能和敏捷性产生巨大影响。

我不能说重要性，但是一旦你设置了数据库并且它已经有数百万行了......改变它将会非常棘手和耗时。排序.. DBA的罪行将在代码中修补。

在敏捷（创建一个可扩展的数据库，能够解决问题或回答你在设计时不知道的问题）和执行/扩展之间，你也必须做出选择。同样，有时候使用代码在实际DB之外创建缓存以创建一些性能可能会更好。

Answer 36

领域理解是最重要的。您必须了解您要对应用程序执行的操作。从域理解，您需要了解您计划存储的信息种类以及信息单元之间的关系。您还需要了解用例。

之后，数据库设计是最重要的。数据库是编制域分析信息的最佳位置。获得所需数据后，应尽可能将数据标准化。然后，您必须了解每个字段的合法值范围，并为每个字段编写数据验证过程（以检查约束，存储过程，正则表达式或其他任何有意义的形式）。

我经常发现，当您的数据高度标准化时，完成应用程序所需的代码量会因以下几个原因而显着下降：

• 您没有编写代码来搜索，排序，索引，加入和分组数据。 SQL为你做了很多。
• 规范化数据不重复。这意味着每次更新都发生在一个且只有一个地方。如果必须编写代码以在许多地方保持数据同步，代码就会变得臃肿且容易出错。
• 您不必编写尽可能多的错误处理代码，因为很多代码都在您的数据验证代码中。
• 当您的代码量下降时，您需要更少的开发人员来维护代码。这意味着不同人拥有的模块不太可能偏离程序的整体意图。

代码仍然很重要，但现在你只需要写很少的代码。