问每个开发人员是否有一个数据库？

EN

如果你们都共享同一个数据库，如果有人对数据库进行了结构更改，并且代码没有与之“同步”，那么您可能会遇到一些问题。

我强烈建议每个开发人员使用一个DB，唯一的原因是你不想做“写”测试，然后看到其他人立即覆盖你。一个简单的例子？你试图为一个网站展示产品。在所有产品消失之前，一切都会正常工作。有问题吗？另一名开发人员决定使用该产品的“活动”标志来测试其他东西。在这种情况下，事务甚至可能无法工作。故事的结尾，你花时间调试别人的动作。

我强烈建议偶尔将临时数据库复制到开发人员数据库，以同步结构(或者更好地，有一个工具从头开始重建数据库)。

当然，我们需要脚本来更改数据库，并且所有内容都在源代码控制中。

数据库环境稀缺的时代已经一去不复返了。我在一台装有5x15k SCSI磁盘的XW9300上写这篇文章。这台机器将在相当合理的时间长度内运行大量的ETL作业，并且(在2007年年中)我在ebay上花费了大约1700 job，包括磁盘。从开发人员的角度来看，特别是在数据仓库等以数据库为中心的项目中，开发人员和DBA之间的界限非常模糊。在我写这篇文章时，我正在为SQL Server2005数据仓库构建一个分区管理框架。

出于以下原因，开发人员应该拥有自己的一个或多个开发数据库(IMO)：

• 要求人们将存储过程、补丁脚本和模式定义文件保存在源代码控制中。补丁的应用可以在相当大的程度上实现自动化。甚至有一些工具，如Redgate SQL Compare Pro，为this.
• Encourages做了大量繁重的工作，因为人们必须在自己的工作站上部署，这是一种简化配置管理和部署的应用程序架构。许多部署问题在投入生产之前很久就会被解决，或者人们甚至意识到他们可能出错了。
• 避免了开发人员在彼此的工作中被绊倒。在像数据仓库这样的东西上，人们正在使用ETL代码，这是一个更大的胜利。
• 它鼓励一定程度的责任，因为开发人员必须学习基本的数据库管理。这还消除了对运营支持人员和一些开发人员的大量要求。ops摩擦。
• 如果你有自己的数据库，就不会有阻碍实验或其他工作的看门人。围绕管理“服务器”的政治消失了，因为没有“服务器”。这在任何具有大量现有bureaucracy.
• For小数据量的环境中都是生产力的胜利，普通PC对此来说已经足够快。开发人员版或许可可用于大多数数据库管理系统，并将在桌面操作系统上运行。如果您正在使用Linux或Unix，这将是一个更小的问题。对于更大的数据量，甚至包括大多数管理信息系统应用程序，像HP XW9400或Lenovo D10这样的工作站可以配备5个15k磁盘，其成本低于许多professional development tooling的成本。(是的，我知道这是双许可证，但QT的商业全平台许可证大约是4000£一个座位)。像这样的机器会比你想象的更快地运行10到100行百万行的ETL进程。
• 它简化了多个环境的设置，用于冒烟测试或协调目的。由于您完全控制了机器，因此在生产环境中模拟条件有很大的余地。例如，我曾经通过绑定一些运行时脚本为Control-M创建了一个简单的仿真器。在您对环境具有这种级别的控制和透明度的情况下，您可以生成一个经过严格测试的部署过程，这在很大程度上消除了生产部署中相互指责的机会。

我见过小团队在14个环境中工作，同时在一个工作站上有7个活动的环境。在数据库繁重的工作中，比如ETL，你需要处理整个表，在单一的开发环境中工作会浪费时间，或者让你的时间如履薄冰。

此外，您还可以为数据库平台使用单用户开发许可证，这可以为您节省仅在数据库许可方面的工作站成本。大多数开发人员许可证(微软和OTN是我熟悉的几个例子)将允许您在单个开发人员免费或象征性价格的单个工作站上使用该系统。

相反，共享开发服务器上的许可条款通常有些模糊，我曾多次看到供应商试图敲诈勒索客户获得开发服务器上的许可。

我们的每个开发人员都有一个功能齐全的数据库。像任何其他代码一样，更改是脚本化的，并且是源代码控制的。