我现在在一些从10人到150人的科技公司工作过，我从来没有遇到过真正的DBA。 在获得DBA之前，公司需要多大的成本？ 什么是需要满足的标准？
（我也在Stack Overflow上发表了这个post，只是在这两个地方，因为一个主持人在那里build议，“这可能是SO和SF都值得去问的罕见情况之一”）
对于很多公司来说，即使他们有一个内置的数据库，他们也不需要全职的DBA。 其他人需要几个DBA。
正如一个人提到的，当丢失数据库的成本超过DBA的工资时，就拿一个。 这是一个非常好的开始。 但是，如果数据库没有那么大的改变，那么一个公司在没有全职DBA的情况下可能会遇到好几年。 这里的诀窍是有一个好的本地（或远程）顾问来处理确保备份是自动的，而其他数据库维护是定期发生的。 让他们每年检查系统几次进行健康检查，并雇用他们来处理大型项目和服务器升级，大部分情况下你应该没问题。
随着公司的发展，最终你会得到一个更初级的人来处理更多的日常事务，但是如果需要的话，还可以随时聘请顾问，直到值得为高级DBA付出代价。
没有规模的公司需要DBA。 我现在所在的公司是一家小型的20人公司，但我们依靠数据库生存和死亡，所以雇用高级DBA是有道理的。 我有一个只有数据库很less变化的内部订单处理系统的百人公司的客户端项目客户端。 我在2007年升级了服务器，并从此以后一直没有回来。 我每隔几个月检查一次，我被告知这个系统很好地哼着，它自动支持，所以我继续我的快乐。
如果你只使用第三方软件，我会说它取决于你将要使用的RDBMS（Oracle，mySQL，DB2，MS SQL等），相对于硬件function的数据大小它将被存储在第三方软件的质量上。 对于易于使用的数据库中的小事情，拥有（愿意）技术人员的基本知识可能就足够了。 起草一个想编写Web代码并迫使她做备份Oracle数据库的开发人员是一个糟糕的主意。
如果您正在进行内部开发，我会询问数据库的扩展需求是什么（您正在构build下一个谷歌或推特，还是保持食谱？）。 DBA要做什么（备份数据库？保护数据库？参与开发？编写代码？架构师数据库模式？扩展或扩展？创build复制scheme？与硬件供应商交互？指定硬件？创build“编码标准”？只是放牧猫？）。
早期引入DBA可以帮助防止项目晚点出现问题，而且现在避免常见的错误通常要比以后修复更为便宜。
我会说这取决于。
既然这是一个企业，那么问自己：“丢失这个数据库的成本是多less？
只要成本大于或等于DBA的工资，就聘请DBA。
“成本”将是一个难以逾越的数字。 但是它应该包括恢复时间，生产力损失（每个用户）和销售损失。 像亚马逊这样的地方（几年前达到每秒60个销售额的峰值）可以明确表示停机时间成本。
一旦你有一个数据库服务器，并开始遇到性能问题，那是得到一个DBA，IMO的时间。 在某些情况下，开发人员有时可能有足够的经验来处理初始数据库configuration。
根据pipe理数据库所花费的资源和时间，数据库所处的位置和关注点是什么？ 许多公司认为，与提供数据库服务的pipe理托pipe服务提供商合作可能更具成本效益和可靠性，然后向可能在一天中大部分时间都处于闲置状态的DBA提供更高的服务，并将其用作“假设”的保险。
这实际上取决于您必须pipe理多less个数据库。 我们有一个现场DBA，他是非常好的。 我们有PROD / TEST / TRAIN / DEV Oracle实例，这些实例需要频繁的安全修补，定期修补和从function方面的回归testing循环后升级。 除此之外，公司还使用Oracle或SQL数据库进行pipe理。 他的任务是保留更新的克隆进行testing，并且还从企业pipe理器内部pipe理RMAN数据库备份。
考虑到我们的数据库是公司的生命线，我认为在某些情况下，您必须拥有一名熟练的DBA。
无论您是否需要聘请DBA，您都需要有人负责生产和开发服务器。
你需要有一个负责生产变化的人员。
在拥有2个以上开发人员的大型项目中，您需要有一个负责人将变更迁移到开发中（从工作站或用户模式）。
如果您计划使用Reporting Services或Analysis服务，则可以查看专门从事这些技术的DBA。
如果你有敏感的数据，你最好确保有人在监视它，并有适当的安全 – 否则你可能会违反政府规定，这需要花钱。
什么时候
我build议一旦数据库开始占用足够的时间以至于无法完成工作，您可以考虑。
试着找一个具有多学科背景的DBA，这样他们除了坐下来等待数据库破解之外还有其他事情要做。
我不相信DBA是需要的。
作为应用程序开发人员，我认为DBA是不必要的 – 任何应用程序端修改都应该由应用程序开发人员完成 – DBA既不能也不应该做这样的更改（实际上，这些更改应该需要经历相同的更改控制和QA作为开发团队的其他变更，所以DBA将成为团队中的一员）。
同样，任何不会改变的应用程序都是系统pipe理员问题，操作团队应该使用他们的变更控制策略来处理，而不是DBA领域。
当我发现什么是好的时候，我会让你知道的。
在我看来，数据库pipe理员不能真正做很多的工作，因为99％是由修改应用程序产生的，哪些操作不应该这样做。
可能在pipe理周期的大约同一时间，值得系统pipe理员，而不是有一个兼职，以及他们的实际工作。
当然这部分是一个轻率的答案，但只有一个意图让你想，你需要一个系统pipe理员通常用于pipe理后端系统的安全性，可用性和性能。 您将需要dba来pipe理数据库系统的安全性，可用性和性能。 在任何一种情况下，当开始花费太多时间时，这项工作是值得分离的，变得太棘手或者消耗太多稀缺的资源。