我是一名有抱负的 DBA（我会说大约 3 年后我会准备好申请工作），我目前是一名程序员。我将我未来的目标传达给了我的一个朋友，他是一家非常繁重且快节奏的软件开发公司的 Agile SCRUM 团队的一员。（SDLC 到核心）。
他表达了他对我的职业道路目标的担忧——指出由于过去 5 到 7 年 ORM 的增加和发展，大多数软件开发公司的 DBA 是一个垂死的职位。他说，公司信任程序员，他们中的大多数人有能力完成 DBA 所做的大部分工作。（存储过程、加密、SQL、备份、ddl、分析等）
任何人都可以阐明他们的经历，或者他们是否对 DBA 职位有相同的担忧/信念？
我指的是 NHibernate 和那些类型的系统。
为了与本网站的问答格式保持一致——如果所有内容都转换为并使用 ORM，那么未来将面临哪些问题，而 DBA 职位不再像过去十年或两年那样重要？
老实说，除了基础研究之外，我没有 ORM 的第一手经验。我知道这个网站应该供专业人士使用，这就是为什么我觉得那些对这种情况了解得更多的人将能够更好地识别问题/问题。
这就是它在小公司中的工作方式，但它过去常常为小公司工作：在小规模上，当所有开发人员都可以做基础工作时，专家数据库人员通常被视为一项巨大的开支。这并不是最近 ORM 和 noSQL 变得流行的真正因素。
ORM 背后仍然有数据存储，需要有人了解并能够监控、备份、修复、分析、扩展和优化，并且随着公司和/或项目的发展，在该领域拥有专家仍然是值得的。信任没有数据处理专业知识的开发人员是通常在小范围内很好，但在扩大规模时可能会导致严重问题。经常看到人们滔滔不绝地谈论 ORM 或 noSQL 解决方案，并声称这意味着他们不需要担心数据库，只是后来当他们在几千条记录上测试的东西在被要求时掉到地板上时才大发牢骚处理数万或数百万甚至更多（对于非常糟糕的设计，有时甚至是“几千加一”），他们很快就到了在问题上投入更多硬件是没有用的地步。你' 你会经常发现创建了大量复杂的缓存层，如果在数据存储的初始设计（或后来的重构）中多考虑一点，就不需要创建这些缓存层——这些层也需要开发和维护，因此这些项目通常不需要没有“数据专家”可以长期节省资金。事实上，如果你能涉足这两个阵营（开发和数据），那么在某些“架构师”角色中会有很多有趣的工作（和丰厚的收入）：人们要么为项目设计模型，要么通过过于复杂的&低效的怪兽，并帮助开发团队将它们变成相对时尚且可扩展的创作。
也不要限制自己成为开发团队的 DBA：我们所有的客户（银行类型、委员会、一两个小型航空公司）都有一个基础设施部门，其中部分由 DBA 组成，他们负责确保他们的数据适当处理。他们挑战我们（和其他供应商）以确保我们遵循良好的做法，他们负责更广泛的问题，例如整合绝望供应商系统的数据，他们当然负责维护内部数据库（镜像、备份、监控，...） - 所以还有其他地方需要 DBA 优化的技能集。
当然，您必须与更新的工具保持同步，这是不言而喻的，但是尽管在过去十年中整体工作发生了一些变化，但它并没有像某些人所相信的那样发生太大变化（我也没有期待它会在不久的将来出现，但请密切关注新的发展情况，以保持最新状态，如果我对此有误，请避免过时）。