根据我的经验，我总是通过使用IP地址，用户名和密码创建新连接来连接到数据库。 我最近加入了一家公司，他们使用以 VB6 编写的桌面应用程序，该应用程序具有 SQL 服务器后端。这里的做法是，备份最新版本的 SQL 服务器并将其命名为不同的数据库，将其用于测试目的。
我们现在遇到一个问题，即我们有很多用户创建的数据库，需要清理。
我的问题：是否有可能拥有一个远程存在的集中式数据库，每个人都可以连接并获取数据？为实现这一目标，我们需要记住哪些事情，因此每个人都可以拥有一个可以访问的数据库，他们可以在哪里进行更改。
答案 0 :(得分：1)
我们已经使用单一的集中式开发/测试环境已有十多年了，最多有50名全职开发人员使用它 - 而且我说它工作得很好。大多数更改是表中的新列，而不是许多开发人员同时使用相同的表/模块，因此它不会导致那么多问题。
我们为每个版本单独重命名所有存储过程/函数（最后通过添加版本号），并自动安装编译过程，即使对于开发人员也是如此。对于开发人员编译，版本号还包括开发人员用户ID。这样改变开发中的存储过程就不会破坏测试环境或其他开发人员正在使用的程序。
这样做的最大优点是我们可以使用类似大小的数据库进行测试和生产。
答案 1 :(得分：0)
这是可能的，但通常不是一个好主意。如果所有数据库访问都只是查询，那就好了（并且不过没问题），但想象一下，如果开发人员在开发者正在编写报告的某些更新中触发，或者如果数据库已恢复，则会出现混乱以不受控制的方式。开发和测试需要大量的管理和需要的数据库，以及在哪里依赖于对开发和测试需求的分析。
答案 2 :(得分：0)
您这样做的能力确实是一个功能性和/或程序性问题。没有任何技术可以阻止您为dev / test创建单个共享数据库。挑战在于，开发/测试环境往往具有破坏性和/或破坏性。
如果您有一个用于所有开发和测试要求的数据库，那么您可能几乎没有工作。一个dev修改对象（SP，FN，表，视图等）可能会破坏其他所有人（或没有人）。一个运行压力测试的测试人员会让其他所有人都对缓慢的响应，超时等感到生气......有人决定测试Always Encrypted，甚至有时候像TDE那样简单，最终会打破所有人。
在办理登机手续之前，开发环境几乎总是需要自己的沙盒。检查代码/模式然后在模拟prod的中心环境中进行测试，然后再进行预制（理想情况下）与prod相同。虽然每个团队/公司都有其变化，但这是非常基本的。
您可以立即做的一件事就是自动执行prod数据库的副本备份，这样您就可以将一个新的.bak放到一个公共位置，每个人都可以从中获取并恢复到自己的实例。这样可以减少对生产系统的影响并减少存储消耗。另一个好处是您删除了对生产数据库的所有非必要访问权限 - 这非常非常重要。最后，一旦这是标准操作，您可以在以后轻松实现进一步的控制或任务（例如，恢复到安全实例，混淆/掩盖敏感数据，为开发/测试使用进行新备份）。
答案 3 :(得分：0)
感谢所有答案。我们在团队中进行了讨论，并提出了适合我们团队的流程：
注意：作为额外的保护措施，我们可以在其他地方保留第一个Master数据库的副本。因此，如果任何人做了一些愚蠢的事情并破坏它，我们可以检索它并运行所有SQL脚本以使其更新。