设计数据库是程序员的工作吗？

在过去的六年中，我一直是一名程序员。在我的整个职业生涯中，我从事许多Web应用程序的工作。

在大多数情况下，当需要数据库时，将数据库交给我们（程序员），或者我们有一些旧数据库可以处理。如果不是那样，我们就必须自己创建和设计数据库，这并不是那么困难。

但是，作为程序员，我们是否应该从头开始创建整个数据库，而我们必须构建新的应用程序，其中数据是如此重要，并且对复杂的数据模型有混乱的要求？

由专家来完成应用程序不是对应用程序和公司的最大利益吗？

我并不是想逃避设计数据库的努力，但是正确地做这件事是如此重要。

首先，如果项目经理告诉您，这是您的工作。较小的公司通常没有专职的数据库专家。无论如何，开发人员和数据库专家之间没有（也不应该）有明显的区别-任何优秀的开发人员都将对DB有相当多的了解，并且任何优秀的DBA都将至少在存储过程中使用DB的语言知道如何编码。 。

尽管数据库设计是应用程序的核心部分，但“正确”并不比许多其他代码所依赖的其他核心部分重要。

就像代码一样，您让一些超级专家坐下来认真思考一个星期，然后写下将永远不需要更改的完美设计的想法是一种幻想。数据库设计可以并且将随着应用程序的开发而改变。

因此，由程序员（非常了解DBs）设计数据库实际上是有益的，因为那样的话，您就有一个了解双方的人。这肯定比只了解数据库并且与其余开发工作无关的人完成它更好。

程序员制作数据库很常见。很常见的。不幸的是，许多程序员没有使用DB的经验。他们不了解如何针对大数据，数据集市，星型模式等进行报告。有些人甚至不了解标准化的基础。

如果一个人具有在专家水平上做所有事情的技能，那么它就是一个很好的产品。一人一支军队可以以十倍于1000倍的质量在短时间内完成十支团队所能完成的工作。不夸张。

假设程序员知道自己在做什么，那么这样做（减少人员）对程序员来说是最大的利益。当然，也有成千上万的失败要指出。

这是一个有趣的问题-有一个强有力的论点，即大多数体面的开发人员应了解如何正确构建关系数据库，也就是说，他们应该能够产生规范化的模式，并根据经验和通用模式进行合理的选择。决定如何存储数据的方式（对我来说，大多数情况下不言而喻，但我知道并不是每个人都这样看）。

此外，如果您先看Entity Framework Code，则表明建立低级数据模型的相同想法将产生合理的模式-或至少暗示一个模式。

因此，不，我不是特别认为您不需要数据库专家来设计数据库架构-至少不需要中小型数据库（这是我从事的工作）。

问题在于，设计好的（或至少是足够的）架构并不是全部内容，尤其是在数据库必须扩展的情况下。在我看来，DBA带来的“附加值”在于获得除基本架构权利以外的其他功能-索引，配置存储，维护数据库（保持文件大小处于检查状态，重建索引等），更智能用户和角色等等。

一个好的程序员应该带来各种各样的技能组合-应该不仅仅是[插入选择的语言]编码人员，而且我将包括对数据库的理解。

我认为设计合理的关系数据库的能力本质上是非初级程序员的必要条件。

话虽如此，尤其是对于大型应用程序，至关重要的是第一次使数据库“正确”（架构，索引等）。如果公司可以使用熟练的DBA，则该任务应由他们自己承担；一般来说，他们会更有资格。潜在的审查/讨论应该与主要的开发人员进行，该开发人员将在客户端访问和使用数据库，以免出现意外。如果没有DBA，则程序员将设计数据库。

我在这里看到两个问题：

• 数据库开发人员应该为业务逻辑建模吗？
• 我应该知道如何将数据持久化到数据库吗？

商业逻辑

• 业务逻辑不存在于数据库中。这是一个概念模型，必须独立于系统中的其他层。

• 您始终可以将一个数据库替换为另一个数据库，或者甚至可以决定使用NoSQL解决方案来解决潜在的性能问题。

• 数据库开发人员可以在建模过程中参与进来，但是通常这是由对问题域有完全了解的人员完成的。在我们的组织中，这是由服务器端开发人员完成的。

• 许多人认为数据库是您应用程序的基础。夯实基础，系统将崩溃。我不同意这一点。我将数据库视为可以随时替换的存储介质。

持久数据

• 您应该知道如何将数据持久保存到不同的存储介质，包括SQL和NoSQL解决方案。

• 所需专业知识的水平将根据您正在使用的系统的大小而变化。

• 当大型公司通常会聘请专家来解决性能，可伸缩性和与安全相关的要求时，小型公司会希望您具有这些知识。

总结一下：

• 域模型是系统的基础，而不是数据库。

• 如果您在一个相对较小的项目中为一家小型公司工作，那么您可能应该自己设计数据库。

• 如果您在企业系统上为大型公司工作，那么将工作交给领域专家可能更有意义。