DBA如何才能更“程序员友好”？

#1 楼

从程序员的角度来看，我想说的是我们最需要的是关于如何设计和构建数据层的一致，定义明确和实现标准。我愿意按照自己想要的方式在沙盒中玩，您只需要告诉我您想要什么，而不是一直更改规则。每个人，甚至超级程序员，都应以相同的方式实现。如果您为他设置例外，那么您希望我支持和更改它，但是以对我不起作用的正确方式重新实施它。那样做就走开。与我一起向我展示您想要什么，以及为什么您的方式更好。如果我理解，我会每次都遵守。如果我不明白，那就很难遵守。我不想成为一名DBA。我喜欢编程，我不想要你的工作，如果你是一个优秀的DBA，那么我将是你的最大粉丝。

#2 楼

在过去的6.5年中，我一直是MySQL DBA。我还花了16年的时间作为开发人员，并且与许多DBA进行了互动。他们中许多人务实。其中一些令人讨厌。有些人不知道成为一名DBA意味着什么。

我得出以下结论：

从技术上讲，具有以下一种或多种素质的DBA是：最好的合作伙伴：


作为开发人员自己度过的岁月
掌握数据库理论
对RDBMS内部工作原理有很好的了解
具有丰富的操作系统知识

非常有纪律，知识渊博的DBA有很多共享和提供的内容。他们可能从开发人员未真正考虑的角度来看数据库性能。开发人员知道他们想要从数据库中获得什么。 DBA知道如何对数据库“礼貌”。就个性而言，总是会有冲突，琐碎甚至是嫉妒。可以肯定的是：在没有特定顺序的情况下，DBA和开发人员就像丈夫和妻子（我已经幸福地结婚了16年，正在进行的项目[有4个孩子]）。

无论谁被视为丈夫而被视为妻子的这些原则适用：


一个人必须咨询另一个人
一个人必须重视另一个人的观点
一个人必须为双方的利益做出决定
一个人必须支持而不是撒谎，如果做出的决定会导致不良后果，一个人就不得贬低对方。双方对决策成功的贡献
如果不能相互商定一项决定，则必须征求上级主管（HA）

这七个原则（7）在工作场所，尤其是在IT领域。

通过沟通每一步，所有人都应：


布置他们的期望
尊重对方根据过去的表现做好自己的工作的能力
对对方可以完成任务的信任和信心
不辜负我们自己的期望

默认在HA的指导下（请参见原则＃7）

这没有进行微管理的空间。 DBA不应告诉开发人员如何像DBA那样思考。开发人员不应告诉DBA如何成为开发人员。关于数据库性能和使用率的最终决定必须取决于DBA。应用程序需求的最终决定权必须由开发人员来决定。必须始终保持这种共生。

最后的想法

原则7需要高层主管（HA）的积极参与和监督，即项目经理，团队负责人，首席开发人员。您的HA会更好地了解双方如何单独工作以及双方如何一起工作。如果房委会没有为双方建立基本规则，或者房委会未能单独或共同指导双方，则项目总是会在某个时刻停顿下来，并危及开发商DBA的生存（就业），甚至是HA。

#3 楼

让团队坐在不同的区域/楼层似乎可以鼓励“我们对他们”的心态。

将DBA设置在开发团队中间是一种消除程序员/ DBA墙的好方法。如果他们保持开放的胸怀并放任自流，DBA和程序员都将从中受益。

面对面的交流，尤其是在分享想法时，比电子邮件有效得多，并且由于误解而引起难受的机会也更少。

#4 楼

这类事情因地而异。在我当前的站点上，开发人员和DBA之间的界限确实非常模糊-我们（DBA）也编写PL / SQL，他们（开发人员）剖析查询计划。我们所有人都将自己视为同龄人，只是具有不同的技能和责任。这非常有趣：最近，该公司加入了DevOps潮流。数据库社区根本不了解这一点。我们一直都这样工作。毋庸置疑，我们的工作方式如此高效：数据库层是迄今为止公司技术堆栈中最可靠的部分，它易于操作（因为我们拥有DBA团队的技能，可以深入理解应用程序，并且开发人员具有DBA经验，可以了解24/7/365的操作以及如何为此构建应用程序）。

但我知道您在谈论“错误的”开发人员时的意思。他自学成才，这本身就是一件高贵的事，但是一路上他对任何形式的指示都不信任。他不知道自己不知道的东西，并且他激怒任何试图启发他的人，他认为这是对他自学技能的侮辱。他学习了命令式的编程风格，因为您可以在没有CS类型总是轻信的任何理论知识的情况下学习它（很好，很糟糕；每个人都需要了解大O和类似的理论知识）。他还学习了一些面向对象，因为他必须使用Java。但是，优秀的数据库专业人员（开发人员或DBA）必须以声明性的方式进行思考，考虑集合论，范式，甚至能够理解关系代数和微积分。与这些人进行交流非常非常困难，因为他们对任何可能使他们脱离舒适区的东西都充满敌意，而这基本上仅限于如何格式化网页上的内容。如果他们完全考虑数据库，他们会认为表就像类，而行就像对象。这些家伙实际上只会执行SELECT * FROM TABLE并对自己的代码进行过滤和排序。他们真的不明白为什么数据库要比平面文件更好（他们并不那么秘密地认为使用关系数据库的人都是白痴）。

让我给你举一个真实的例子：最近，我正在与其中一种类型进行交流，讨论如果某个软件的质量问题超出了质量检查范围，则该软件在投入生产后回滚该软件所涉及的问题。我解释说，尽管我们可能回滚他的应用程序（许多访问数据库的应用程序之一），但它仍需要能够在仍部署了数据库的情况下运行。他问为什么，我说的很好，在那些新的表格和栏中，会有真实的客户数据。然后他说，所以只需将其复制到临时表中，出了什么问题。我难以置信地盯着他看：当一个客户打电话说时，我的钱已经从我的帐户中消失了，我们怎么告诉他，没关系，它在一张临时桌子上？当您处理别人的钱时，他简直没有明白，您必须像一个负责任的成年人那样行事。就我所知，他仍然没有。他不再和我们在一起了。

MySQL阵营已经很长时间了。他们会说您不需要事务，外键等，如果您以为是因为那是因为您不知道自己在做什么，等等，等等（然后当它们长大后，他们便悄悄地添加了它们）。这些是像ActiveRecord或Hibernate这样的ORM开发人员，因此他们无需编写SQL就可以编写数据库应用程序。我认为使用这些技术是一个危险信号-这不是一家重视DBA技能的公司。他们真正想要的是保姆...

#5 楼

作为程序员，更好地了解数据库使我成为了更好的程序员。当我成为数据库管理员时，这一点变得更加重要，因此我相信教育是关键。

DBA应该耐心地指导开发人员将其视为合格的专业人员。很少有程序员在客户端看到set操作与逐行操作之间的差异时会接受这种想法。我们具有一些相同的目标-应用程序速度，数据安全性，可维护性等。这不仅适用于应用程序逻辑问题，而且还适用于数据库交互的所有方面。程序员希望更好地使用他们的工具，而DBA可以向他们展示如何更好地使用数据库工具，这两者对他们越有好处。

#6 楼

无论我们支持哪种基础架构，我们都必须支持它的用户。很多用户都是开发人员，因此我们支持开发人员，使他们能够充分利用该基础架构。为了做到这一点，我们需要相互了解，并牢记不同的观点和观点。洞悉双方的观点有助于使事情变得更好，这是我们共同的目标。使IT尽可能有效地支持业务。

在许多组织中，我们看到某些dba类型以上帝模式运行。在大多数情况下，如果衡量能力，这些得分都不是很好。...通常，他们只是将自己的-缺乏-知识隐藏在文字墙后面。

我认为与“程序员友好”与专业无关。对于dba，这意味着我们需要能够解释为什么我们要做我们要做的事情，并准备在租赁时重新考虑是否有帮助的决定，而又不会失去可用性，可伸缩性，可恢复性和性能等正常目标。对于程序员来说，这意味着他必须与dba交流，有时要教dba，有时要向dba学习。我的座右铭是：让我什么都不学的第一天是棺材闭上头顶的那一天。正常的协作，将团队与开发人员和dba合并在一起肯定有助于简化工作。

#7 楼

我认为问题的一部分是透视。 Dbas和数据分析人员以及数据库开发人员必须随着时间处理数据。应用程序开发人员关心将事物发送到生产环境时如何使其工作。只要部署时没有错误，他们就不必担心六个月后的数据情况如何。

但是数据人员必须忍受目光短浅的决策结果，这些决策会导致数据丢失完整性或导致插入重复的记录，然后尝试解释为什么数据不好。当只有一千条记录时，DBA不得不从性能良好的过程中解决性能问题，而现在，拥有一亿条记录需要花费数小时。

数据库很难重构，因此DBA关心第一次将其正确设置。开发人员认为在重构过程中没有问题。

开发人员认为使数据库像面向对象一样工作没有问题，数据库人员知道这不是存储或获取数据的最有效方法。

应用程序开发人员通常只处理一小部分记录，而不处理大数据导入/导出或报告。可以很好地输入一个记录，而在谈论导入一百万个记录时则无效。应用程序中的业务逻辑（报表应用程序通常无法访问该业务逻辑）无法帮助报表编写者获得一百万条记录的相同结果，而不是一次显示一条记录。 />问题的另一部分是双方都不尊重。我遇到了许多应用程序开发人员，他们认为数据工作并不困难或有趣，并且认为只有在无法破解数据的情况下，您才可以从事这项工作。人们往往对愚蠢和无用的对待不善。另一方面，某些DBA也倾向于不尊重应用程序开发人员，并倾向于将其审查数据库的开发人员工作的任务作为低优先级来处理（当您拥有大型复杂生产数据库时，可能是这样）。他们可以拒绝听见或做出回应。谁希望他的整个项目搁置，直到DBA在两周后对其进行审查？然后他告诉您这是不可接受的，您必须重写整个内容？

#8 楼

自从我开始使用SQL Server（1998）以来的许多年里，我有许多开发人员告诉我如何完成工作。有趣的是，他们都是出色的.net开发人员，他们比我了解更多。实际上，他们也是建筑师，应该做的比代码胡闹还要大。

也许这是我的错误态度：但这在许多商店中都是开发人员的普遍态度。他们也彼此做到这一点，请记住：观看比赛在您建议同行评议时开始。

我将把修复工作留给其他答案（到目前为止，我100％同意2个答案），但是补充说，管理和商店文化也必须支持和培育协作。

#9 楼

作为开发人员，我所需要的只是了解您如何让我传达我的需求。如果我要的是荒谬的事情，我需要您告诉我-如果您这样告诉我，我会相信，因为您拥有诚信的往绩。如果您不明白我的要求，请花时间向我解释您的意思-我会花时间听。

...正确的主题，正确的...交流...交流...交流。

确实没有更好的方法来表达它。开发人员被打勾是因为“ DBA告诉我这不可能完成-我确定上次证明他是错误的。” DBA被打勾是因为“开发人员每次更改规格都不了解我必须做什么”。

@Rolando指出，开发人员和DBA必须相互理解。当一切归结为它时，我们都说“ Ones＆Zeros”-您会认为这是一个很好的匹配。我们有2个责任领域：DBA有数据，开发人员得到了其余的计算机。但是，如果没有数据，程序员实际上将无事可做。

我们没有DBA，有时会很痛苦。当我看到我们所做的某些事情时，我想成为十年前的DBA的那部分人会感到畏缩。如果我们明天雇一名DBA，我想我会亲吻他/她走过的那一面。

#10 楼

在某些公司（也许很多公司）中，产品开发趋向于忽略任何未使用编译语言编写的人。发布时间到了，因为网络管理员，DBA，系统管理员，用户支持等都需要尽职调查，所以存在阻力。由于没有考虑环境的关键方面，因此经常会头疼。这自然会引起团队之间的紧张关系。

这是谁的责任？ Communication女士。

开发人员需要了解将在其中部署环境代码。需要给人们以公平的警告以进行适应。如果环境由于某种原因（安全性，设备，策略）无法适应，则软件需要适应。如果在设计和实施过程中发生这种情况，每个人都会感到高兴。如果要等到部署时间才能开始，那将是一个很大的伤害。

是的，团队需要彼此交谈（和倾听），但是项目/产品经理需要创建环境

我很幸运，在我工作过的大多数地方，相互尊重和沟通一直是这种文化的一部分。

#11 楼

一个好的DBA必须了解的一件事是数据的政治性。几年来，我曾向经验丰富的程序员和几位起草过的DBA教授数据库编程和设计。
经常会出现一个问题：这是为什么回到我店里的所有数据库都如此政治化？

这是我的标准答案：如果数据库有用，那么您正在共享数据。如果要共享数据，那么就意味着共享权力。当权力共享时，政治就发生了。

无论你热爱政治还是讨厌政治。如果您要做好数据库工作，请习惯一下。有一些DBA在围栏的生产方面工作，与开发人员的互动很少。您可能会认为生产中的政治问题较少。还有更多。大型生产数据库通常在整个企业范围内，并且对任务至关重要。

#12 楼

谦虚一点可能对某些人有所帮助。 ;）

这两种方法显然都有有效的论据，我建议您从认识到这一点开始。软件开发就是要进行正确的权衡。如果这是一条双向路，也许DBA也应该保持开放的态度。