与DBA相比，构建数据是软件工程师的责任吗？

Question

作为一家小公司的后端工程师，我们遇到了一个问题:我们是否需要一个DBA或另一个后端工程师(SWE2)。这个问题之所以是一个问题，是因为在定义角色方面存在困难。

对我们来说，我们正在考虑DBA作为至少做以下工作的人所扮演的角色：

1. 管理数据库实现(我们使用哪个DB来处理哪些数据集及其优化)
2. 管理备份、保护查询和处理服务器端问题。
3. 调查性能问题

然而，我们认为有必要的下列任务很难界定为一项任务，或者说在短期内可能比前者更重要：

1. 提供关于如何在我们的db实现中构造特定数据的输入(哪些列、哪种类型，以及为什么-在-是和将来的数据上)
2. 根据系统变化、应用需求、效率来处理数据结构的重组

我的理解是，软件工程师或至少是后端工程师的角色只是检索和处理数据，而不一定要负责决定其结构(在数据库端，而不是在应用程序端)。这是误会吗？

按照我的定义，这意味着沟通链应该在一个小团队中像这样工作：

1. PM定义功能请求。
2. 关于需要处理哪些新数据点以及如何处理的内部讨论
3. 关于如何构造数据的内部讨论
4. 最后确定数据结构设计(哪些列以及为什么)
5. DBA/SWE2创建新的数据结构
6. SWE1实现了处理新公开的数据结构的新特性

像这样写出来让我感觉到硬定义的DBA并不是必要的，但是关于数据应该以何种方式构建在数据库中以便于查询的专业知识和有价值的输入似乎通常不属于SWE的主要技术范畴。然而，必须与另一个角色来回交流才能完成基本和基本的任务，这似乎违反了某种效率原则。

这是否意味着需要一个DBA？还是说SWE2必须有关于数据库的特定领域知识？这个人还有其他术语吗?有必要吗？SWE1是否应该简单地学习如何为高效的查询和缩放适当地构造数据的必要步骤？

Answer 1

糟糕的软件工程师首先设计算法，然后再设计数据结构。

另一方面，优秀的软件工程师首先设计数据结构，然后再设计算法。如果你想看看这种方法创造了什么了不起的软件产品，只要看看Git --他们按照正确的顺序做事，先决定优秀的数据结构，然后再做压缩之类的事情，才能真正提高效率。

我想说你需要一个优秀的软件工程师，拥有足够的数据库知识。DBA可能对软件工程了解不够，无法了解数据的最优结构。如何存储数据是软件工程师面临的问题。

但是，如果您有一个决定哪些列被存储以及为什么存储的过程，我看不出您将如何需要SWE2/DBA。我是说，'create table‘命令不是有史以来最琐碎的事情吗？当然，SWE1输入这些命令并不需要太多的工作。

划分工作任务并不取决于它们是否触及数据库或应用程序逻辑，而是取决于它们所涉及的产品的特性。例如，SWE1可以实现FEATURE1，SWE2可以实现FEATURE2。不是SWE1实现了FEATURE1和FEATURE2应用程序逻辑，SWE2实现了FEATURE1和FEATURE2数据库表。

我还想说，SWE1需要非常积极地参与有关数据结构设计的内部讨论。实际上，要能够看到什么是最优的数据结构，就需要一些关于如何实现事物的愿景。

只有您可以说您是否需要SWE2，或者SWE1是否足够。但是，如果您确实需要SWE2，则需要认真地重新考虑在SWE1和SWE2之间划分工作的方式。

我想说的是，您今天唯一需要的是数据库备份和将数据库更新到更新版本。甚至像数据库查询性能这样的事情都涉及到应用程序逻辑，以至于仅靠DBA无法使数据库表现良好。为此，您需要对数据库性能有足够了解的SWE。