Jac*_*las 46 database-design best-practices
dba.se 版本和programmers.se 版本的问题“反对或支持将应用程序逻辑置于数据库层的论据是什么？”的答案和评论。在某些工作场所中，DBA 和程序员之间的鸿沟非常具有启发性。
DBA 可以采取哪些不同的方式来更好地与程序员合作解决此类问题？
我们应该吗：
Rol*_*DBA 63
在过去的 6.5 年里，我一直是 MySQL DBA。我还做了大约 16 年的开发人员，并与许多 DBA 打过交道。他们中的许多人务实。其中一些令人讨厌。有些人不知道成为 DBA 意味着什么。
我得出了这个结论：
从技术上讲，具有以下一项或多项素质的 DBA 最适合与之合作：
非常有纪律、知识渊博的 DBA 有很多东西可以分享和提供。他们可能会从开发人员并未真正考虑的角度看待数据库性能。开发人员知道他们想要从数据库中获得什么。DBA 知道如何对数据库保持“礼貌”。
就性格而言，总会有冲突、小气，甚至嫉妒。有一件事是肯定的：DBA 和开发人员没有特别的顺序，就像丈夫和妻子（我已经幸福地结婚 16 年了，有正在进行的项目 [4 个孩子]）。
无论谁被视为丈夫，谁被视为妻子，这些原则都适用：
这七 (7) 条原则同样适用于工作场所，尤其是 IT 领域。
通过沟通每一步，所有人都应该：
在这方面没有微观管理的余地。DBA不应该告诉开发人员如何像 DBA 一样思考。开发人员不应该告诉DBA 如何成为开发人员。数据库性能和使用的最终决定必须由 DBA 决定。关于应用程序需求的最终决定必须由开发人员决定。这种共生关系必须始终保持。
原则#7 需要更高权力机构（HA），即项目经理、团队领导、首席开发人员的积极参与和监督。您的 HA 更好地了解双方如何单独工作以及双方应如何合作。如果 HA 没有为双方制定基本规则，或者如果 HA 未能单独和共同指导双方，项目将总是在某个时候停止并危及开发商、DBA、甚至HA。
dat*_*god 28
让团队坐在不同的部分/楼层似乎会鼓励“我们与他们”的心态。
将 DBA 置于开发团队的中间是拆除程序员/DBA 墙的好方法。如果 DBA 和程序员保持开放的心态并把自负放在一边，他们都会从中受益。
面对面的交流，尤其是在分享想法时，比电子邮件有效得多，并且由于误解而引起不适的机会更少。
Cha*_*had 27
从程序员的角度来看，我会说我们最想要的是关于如何设计和构建数据层的一致、明确定义和实施的标准。我愿意在你的沙盒中以你想要的方式玩，你只需要告诉我你想要什么，而不是一直改变规则。它应该对每个人都实施相同的，甚至是超级程序员。如果你为他破例，那么你希望我支持并改变它，但以对我不起作用的正确方式重新实现它。
请不要告诉我不要那样做，然后走开。和我一起工作，向我展示你想要什么，以及为什么你的方式更好。如果我理解，我每次都会遵守。当我不明白时，就更难遵守。我不想成为 DBA。我喜欢编程，我不想要你的工作，如果你是一名优秀的 DBA，那么我将是你最大的粉丝。
Gai*_*ius 20
这种事情因地而异。在我当前的站点上，开发人员和 DBA 之间的界限确实非常模糊——我们（DBA）也编写 PL/SQL，他们（开发人员）剖析查询计划。我们都将自己视为同龄人，只是技能和职责不同。这非常有趣：最近该公司加入了DevOps 的行列。数据库社区根本不了解这一点；我们一直都是这样工作的。毋庸置疑，我们的工作效率非常高：数据库层到目前为止公司技术堆栈中最可靠的部分，易于操作（因为我们在 DBA 团队中拥有深入了解应用程序的技能，而开发人员则具有 DBA 经验，可以了解 24/7/365 操作以及如何为其构建应用程序）。
但是我知道您在谈论“错误”类型的开发人员时的意思。他是自学成才的，这本身就是一件高尚的事情，但在此过程中，他开始不信任任何形式的正式指示。他不知道他不知道的东西，他憎恨任何试图启发他的人，他认为这是对他自学能力的侮辱。他学会了命令式编程风格，因为你可以在没有任何 CS 类型总是喋喋不休的理论东西的情况下学习它（好吧，很糟糕；每个人都需要知道big-O和类似的理论）。他也学了一点 OO，只是因为他必须使用 Java。但是一个好的数据库专业人士——开发人员或 DBA——必须能够以声明式的方式进行思考，思考集合论、范式，甚至能够理解关系代数和微积分。与这些人交流非常非常困难，因为他们对任何可能使他们脱离舒适区的事物充满敌意，而这基本上仅限于如何在网页上格式化某些内容。如果他们完全考虑数据库，他们会认为表就像一个类，一行就像一个对象。这些家伙实际上只是在他们自己的代码中SELECT * FROM TABLE对结果进行过滤和排序. 他们真的，真的不明白为什么数据库比平面文件更好（他们不那么秘密地认为任何使用关系数据库的人都是白痴）。
让我给你举一个真实的例子：最近我正在和其中一种类型的人讨论在我们的软件投入生产后回滚软件版本所涉及的问题，如果问题已经过去了 QA。我解释说，虽然我们可能会回滚他的应用程序（许多访问数据库的应用程序之一），但它需要能够在仍部署的数据库下运行。他问为什么，我说，嗯，在那些新的表和列中，会有真实的客户数据。然后他说，所以就复制到一个临时表中，有什么问题。我难以置信地盯着他：当一个客户打电话说，我的钱从我的账户里消失了，我们该怎么告诉他，没关系，放在临时表里？他只是不明白，当你处理别人的钱时，你必须表现得像一个负责任的成年人。据我所知，他仍然没有；他不再和我们在一起了。
MySQL阵营很长一段时间都是这样；他们会说你不需要事务、外键等，如果你认为你这样做只是因为你不知道自己在做什么，等等（然后当他们长大后，他们悄悄地添加了它们）。这些是像 ActiveRecord 或 Hibernate 这样的 ORM 是为这些人开发的，因此他们可以编写数据库应用程序而无需接触 SQL。我认为使用这些技术是一个危险信号——这不是一家重视 DBA 技能的公司。他们真正想要的是一个保姆……
Lei*_*fel 18
作为一名程序员，更好地了解数据库使我成为一名更好的程序员。当我成为数据库管理员时，这变得更加重要，因此我相信教育是关键。
DBA 应该耐心地指导开发人员将他们视为合格的专业人员。当在客户端显示设置操作和逐行操作之间的区别时，很少有程序员会拒绝这个想法。我们有一些相同的目标——应用程序速度、数据安全性、可维护性等。这不仅适用于应用程序逻辑问题，也适用于数据库交互的所有方面。程序员希望更好地使用他们的工具，DBA 向他们展示如何更好地使用数据库工具的次数越多，他们就越受益。
ik_*_*elf 12
无论我们支持什么基础设施，我们都必须支持它的用户。许多用户都是开发人员，因此我们支持开发人员，使他们能够最好地利用该基础设施。为了能够做到这一点，我们需要相互理解，考虑到不同的想法和观点。洞察双方的观点有助于使业务变得更好，这是我们的共同目标。使 IT 尽可能有效地支持业务。
在许多组织中，我们看到一些 dba 类型以上帝模式运行。大多数情况下，如果衡量能力，这些都不是得分很高的人......通常他们只是将他们的 - 缺乏 - 知识隐藏在文字墙后面。
在我看来，这与“对程序员友好”无关，而与专业无关。对于 dba 来说，这意味着我们需要能够解释我们为什么要做我们所做的事情，并准备好重新考虑决定是否有帮助，而不会失去可用性、可扩展性、可恢复性和性能等正常目标。对于程序员来说，这意味着他必须与 dba 沟通，有时要教 dba，有时要向 dba 学习。我的座右铭是：让我第一天什么都没学到，棺材在我头顶合上。正常的协作，将团队与开发人员和 dba 结合起来肯定有助于使事情变得更容易。
我认为问题的一部分是视角。随着时间的推移，数据库管理员和数据分析师以及数据库开发人员必须处理数据。应用程序开发人员关心如何在将其发送到生产环境时使其工作。只要在部署时没有错误，他们就不会太担心六个月后的数据会是什么样子。
但是数据人员必须忍受短视决策的结果，这些决策导致数据失去完整性或导致插入重复记录，然后试图解释数据为什么不好。DBA 必须处理流程中的性能问题，该流程在只有 1000 条记录时运行良好，但现在处理 100,000,000 条记录需要数小时。
数据库更难重构，因此 DBA 关心的是第一次就正确。开发人员认为重构没有问题。
开发人员认为使数据库像面向对象一样运行没有问题，数据库人员知道这不是存储或获取数据的最有效或最高效的方式。
应用程序开发人员通常只处理一小部分记录，而不处理大数据导入/导出或报告。输入一条记录可以正常工作的东西，当您谈论导入一百万时就行不通了。应用程序中的业务逻辑（报告应用程序通常无法访问）并不能帮助报告编写者获得与屏幕上一次显示一个记录相同的百万条记录的结果。
问题的另一部分是双方的不尊重。我遇到过不少应用程序开发人员，他们认为数据工作并不难或有趣，并且认为只有在他们的世界中无法破解它，你才会做这项工作。人们往往不会对被视为愚蠢和无用的人做出很好的反应。另一方面，一些 DBA 也倾向于不尊重应用程序开发人员，并且倾向于将审查开发人员对数据库所做的工作的任务视为低优先级（当您拥有大型复杂的生产数据库时，它可能是）。他们可以拒绝倾听或做出回应。谁希望他的整个项目在两周后 DBA 审查之前搁置？然后他告诉你这是不可接受的，你必须重写整个事情？
自从我开始使用 SQL Server（1998 年）以来的许多年里，有很多开发人员告诉我如何完成我的工作。有趣的是，他们都知道的比我多，以及被精湛的.NET开发人员。事实上，他们也是架构师，应该做比代码猴子更重要的事情。
也许这是我的错误态度：但这是许多商店中非常普遍的开发人员态度。他们也互相这样做，请记住：当您建议同行评审时，观看战斗开始。
我会将修复留给其他答案（到目前为止我 100% 同意 2），但补充说管理和商店文化也必须支持和培养协作。
作为一名开发人员，我需要从你那里知道你希望我如何传达我的需要。如果我要求一些荒谬的事情，我需要你告诉我 - 如果你告诉我，我会相信，因为你有诚信的记录。如果你不明白我的要求，请花时间向我解释你认为我的意思——我会花时间倾听。
... 共同的主题，对 ... 交流 ... 交流 ... 交流。
真的没有更好的方式来表达它。开发人员被打勾是因为，“那个 DBA 告诉我这是不可能的——我上次证明他错了。” DBA 被打勾是因为，“那个开发人员不明白每次他改变他的规范时我必须做什么。”
正如@Rolando 所说，开发人员和 DBA 必须相互理解。归根结底，我们都说“Ones & Zeros”——你会认为这是一个很好的匹配。我们有两个责任领域：DBA 拥有数据，开发人员拥有计算机的其余部分。但是如果没有数据，程序员真的没有多少事可做。
我们没有 DBA，有时很痛苦。当我看到我们所做的一些事情时，我十年前想成为 DBA 的那部分人会感到畏缩。如果我们明天聘请 DBA，我想我会亲吻他/她走过的土地。
在一些公司，也许是很多公司，产品开发倾向于忽略任何不是用编译语言编写的人。到了发布时间，就会遇到阻力，因为网络管理员、DBA、系统管理员、用户支持等每个人都有自己的尽职调查要完成。因为没有考虑环境的关键方面，所以常常令人头疼。这自然会导致团队之间的紧张关系。
这里的罪魁祸首是谁？通讯小姐。
开发人员需要了解将部署代码的环境。人们需要得到公平的警告以适应。在环境因任何原因（安全、设备、策略）无法适应的情况下，软件需要适应。如果在设计和实施过程中发生这种情况，每个人都会很高兴。如果它直到部署时间才开始，那将是一个痛苦的世界。
是的，团队需要互相交谈（和倾听），但项目/产品经理需要创造一个可以发生这种情况的环境。
我很幸运，在我工作过的大多数地方，相互尊重和沟通一直是文化的一部分。
一名优秀的 DBA 必须了解的一件事是数据政治。几年来，我向经验丰富的程序员和一些起草的 DBA 教授数据库编程和设计。经常出现的一个问题是：为什么我店里的所有数据库都如此政治化？
这是我的标准答案：如果数据库有用，那么您就是在共享数据。如果您正在共享数据，那么您就是在共享权力。当权力被分享时，政治就会发生。
不管你喜欢政治还是讨厌政治。如果您要做好数据库工作，请习惯它。
顺便说一句，你们中的一些人只在开发环境中工作过。有些 DBA 在围栏的生产端工作，与开发人员几乎没有互动。您可能认为生产中的政治较少。还有更多。大型生产数据库往往适用于企业范围和关键任务。