关于问题“在数据库层中放置应用程序逻辑或将其放置在数据库层中的参数是什么？”的dba.se版本和programmers.se版本的答案和注释。在某些工作场所中，DBA和程序员之间的鸿沟非常明显。
在这样的问题上，DBA有什么不同的方法可以更好地与程序员合作？
我们应该吗：
Answers:
在过去的6.5年中，我一直是MySQL DBA。我作为开发人员也已经花费了16年的时间，并且与许多DBA进行了互动。他们中许多人务实。其中一些令人讨厌。一些人不知道成为DBA意味着什么。
我得出了这个结论：
从技术上讲，具有以下一种或多种素质的DBA是最好的选择：
纪律严明，知识渊博的DBA有很多共享和提供的内容。他们可能从开发人员未真正考虑的角度来看数据库性能。开发人员知道他们想要从数据库中获得什么。DBA知道如何对数据库“礼貌”。
就个性而言，总是会有冲突，琐碎甚至是嫉妒。可以肯定的是：在没有特定顺序的情况下，DBA和开发人员就像丈夫和妻子（我已经幸福地结婚了16年，正在进行的项目[有4个孩子]）。
无论谁被视为丈夫，谁被视为妻子，这些原则均适用：
这七个（7）原则同样适用于工作场所，尤其是在IT领域。
通过沟通每一步，所有人都应：
在此没有微管理的空间。DBA 不应告诉开发人员如何像DBA那样思考。开发人员不应告诉 DBA如何成为开发人员。关于数据库性能和使用率的最终决定必须取决于DBA。应用程序需求的最终决定权必须由开发人员决定。这种共生必须始终保持。
原则7需要高层主管（HA）的积极参与和监督，即项目经理，团队负责人，首席开发人员。您的HA会更好地了解双方如何单独工作以及双方如何一起工作。如果房委会没有为双方建立基本规则，或者房委会未能单独或共同指导双方，则项目总是会在某个时候停下来，并危及开发商DBA的生存（就业），甚至医管局
这类事情因地而异。在我当前的站点上，开发人员和DBA之间的界限确实非常模糊-我们（DBA）也编写PL / SQL，他们（开发人员）剖析了查询计划。我们所有人都将自己视为同龄人，只是具有不同的技能和责任。这非常有趣：最近，该公司加入了DevOps潮流。数据库社区根本不了解这一点。我们一直都这样。不用说，我们的工作效率如此之高：到目前为止，数据库层它是公司技术堆栈中最可靠的部分，易于操作（因为我们拥有DBA团队的技能，可以深入理解应用程序，而开发人员则具有DBA的知识，可以了解24/7/365的操作以及如何为其构建应用程序）。
但是当您谈到“错误的”开发人员时，我知道您的意思。他自学成才，这本身就是一件高贵的事，但一路上他对任何形式的指示都不信任。他不知道自己不知道的东西，并且他激怒任何试图启发他的人，他认为这是对他自学技能的侮辱。他学习了命令式的编程风格，因为您可以不用CS类型总是轻信的任何理论知识就可以学习它（嗯，很糟糕；每个人都需要知道big-O和类似的理论）。他还学习了一些面向对象，因为他必须使用Java。但是，优秀的数据库专业人员（开发人员或DBA）必须以声明性的方式进行思考，考虑集合论，范式，甚至能够理解关系代数和微积分。与这些人进行交流非常非常困难，因为他们对任何可能使他们脱离舒适区的东西都充满敌意，而这基本上仅限于如何格式化网页上的内容。如果他们完全考虑数据库，他们会认为表就像类，而行就像对象。这些家伙将SELECT * FROM TABLE按照他们自己的代码进行处理，过滤和排序。他们真的，真的不理解为什么数据库比平面文件更好（他们并不那么秘密地认为使用关系数据库的任何人都是白痴）。
让我给你一个真实的例子：最近，我正在与一种类型的软件进行讨论，讨论如果某个软件的问题超出了质量检查范围，则该软件在投入生产后回滚该软件所涉及的问题。我解释说，尽管我们可能回滚他的应用程序（许多访问数据库的应用程序），但它仍需要能够在仍部署了数据库的情况下进行操作。他问为什么，我说的很好，在那些新表和新列中，将有真实的客户数据。然后他说，所以只需将其复制到临时表中，出了什么问题。我难以置信地盯着他看：当一个客户打电话说时，我的钱已经从我的帐户中消失了，我们怎么告诉他，没关系，它在一张临时桌子上？当您在与他人的金钱打交道时，他根本没有意识到，您必须像一个负责任的成年人那样行事。就我所知，他仍然没有。他不再和我们在一起。
MySQL阵营长期以来就是这样。他们会说您不需要事务，外键等，如果您以为这样做是因为您不知道自己在做什么，等等，等等（然后当他们长大后，他们悄悄地将它们添加进来）。这些是像ActiveRecord或Hibernate这样的ORM开发人员，因此他们无需编写SQL即可编写数据库应用程序。我认为使用这些技术是一个危险信号-这不是一家重视DBA技能的公司。他们真正想要的是保姆...
无论我们支持哪种基础架构，我们都必须为它的用户提供支持。很多用户都是开发人员，因此我们支持开发人员，使他们能够充分利用该基础架构。为了做到这一点，我们需要相互了解，并牢记不同的观点和观点。洞悉双方的观点有助于使事情变得更好，这是我们共同的目标。使IT尽可能有效地支持业务。
在许多组织中，我们看到某些dba类型以上帝模式运行。在大多数情况下，如果衡量能力，这些得分都不是很好。.....通常，他们只是将自己的-缺乏-知识隐藏在文字墙后面。
在我看来，这与“程序员友好”无关，而与专业无关。对于dba，这意味着我们需要能够解释为什么我们做我们要做的事情，并准备在需要时重新考虑决策（如果有帮助的话），而又不会失去诸如可用性，可伸缩性，可恢复性和性能之类的正常目标。对于程序员来说，这意味着他必须与dba交流，有时要教dba，有时要向dba学习。我的座右铭是：让我什么都不学的第一天是棺材闭上头顶的那一天。正常的协作，将团队与开发人员和dba相结合，无疑将使事情变得容易。
我认为问题的一部分是透视。Dbas和数据分析师以及数据库开发人员必须随着时间处理数据。应用程序开发人员关心将事物发送到生产环境时如何使其工作。只要部署时没有错误，他们就不必担心六个月后的数据情况如何。
但是，数据人员必须忍受目光短浅的决策结果，这些决策会导致数据丢失完整性或导致插入重复的记录，然后尝试解释为什么数据不好。当只有一千条记录时，DBA不得不处理那些性能良好的过程中的性能问题，但是现在需要几小时才能处理一亿条记录。
数据库更难重构，因此DBA关心的是第一次将其正确设置。开发人员认为在重构过程中没有问题。
开发人员认为使数据库像面向对象一样工作没有问题，数据库人员知道这不是存储或获取数据的最有效或最有效的方法。
应用程序开发人员通常只处理一小部分记录，而不处理大数据导入/导出或报告。可以很好地输入一个记录的东西，而当您谈论导入一百万个记录时则无效。应用程序中的业务逻辑（报表应用程序通常无法访问该业务逻辑）无法帮助报表编写者获得一百万条记录的相同结果，而不是一次显示一个屏幕上的记录。
问题的另一部分是双方都不尊重。我遇到了许多应用程序开发人员，他们认为数据工作并不辛苦或有趣，他们认为只有在无法破解数据的情况下，您才能进行这项工作。人们往往对愚蠢和无用的对待不善。另一方面，某些DBA也倾向于不尊重应用程序开发人员，并倾向于将其对数据库的开发人员的工作进行审查的任务作为低优先级来处理（当您拥有大型复杂生产数据库时，可能是这样）。他们可以拒绝听见或做出回应。谁希望他的整个项目搁置，直到DBA在两周后对其进行审查？然后他告诉您这是不可接受的，您必须重写整个内容吗？
作为开发人员，我所需要的只是了解您如何让我传达我的需求。如果我要的是荒谬的事情，我需要您告诉我-如果您这样告诉我，我会相信，因为您拥有诚信的往绩记录。如果您不明白我的要求，请花时间向我解释您的意思-我会花时间听。
...共同的主题，正确的...沟通...沟通...沟通。
确实没有更好的方法来表达它。开发人员被打勾是因为“ DBA告诉我无法完成-我确定上次证明他是错误的。” DBA被打勾是因为“开发人员每次更改规格都不了解我必须做什么”。
正如@Rolando所说，开发人员和DBA必须相互理解。归根结底，我们俩都说“ Ones＆Zeros”（零）-您会认为这是一个不错的选择。我们有2个责任领域：DBA有数据，开发人员拥有计算机的其余部分。但是，如果没有数据，程序员实际上将无事可做。
我们没有DBA，有时会很痛苦。当我看到我们所做的某些事情时，那想十年前成为DBA的人会感到畏缩。如果我们明天雇一名DBA，我想我会亲他/她走路的那一刻。
在某些公司（也许很多公司）中，产品开发趋向于忽略任何未使用编译语言编写的人。发布时间到了，因为网络管理员，DBA，系统管理员，用户支持等都需要尽职调查，因此存在阻力。由于没有考虑环境的关键方面，因此经常会头疼。这自然会导致团队之间的紧张关系。
谁应该在这里责怪？通讯女士
开发人员需要了解将在其中部署环境代码。需要向人们提供合理的警告以进行适应。如果环境由于某种原因（安全性，设备，策略）无法适应，则软件需要适应。如果在设计和实施过程中发生这种情况，每个人都会感到高兴。如果直到部署时才开始，那将是一个很大的伤害。
是的，团队需要互相交谈（和倾听），但是项目/产品经理需要创建一个可能发生的环境。
我很幸运，在我工作过的大多数地方，相互尊重和沟通一直是这种文化的一部分。