除了“只是 SQL”之外，数据库管理员在多大程度上需要了解系统或应用程序级编程语言（例如 .NET 或 PHP）？
就本问题而言，此答案（SQL ANSI 86、SQL ISO 87、SQL:2008）不考虑特定版本的 SQL 标准，因为该问题与 SQL 领域之外的桌面或服务器语言有关。
背景
我正在为大约 4 名程序员和 4 名设计师的小型网络团队创建一个新的开发流程，该团队在未来具有明显的发展潜力。我们的产品是一个中央应用程序，它为我们设计和托管的客户网站提供支持。
以前，我们都通过 FTP 在开发服务器上工作，使用单个开发数据库。这“工作” *了一段时间，但我们正在进入一个新的发展方向，所以它是成熟的时间我们的进程。
我们使用 Percona Server 5.5，但这应该是数据库不可知的，以保持低成本的想法。
目标：
我正在考虑为数据库开发创建持续集成 (CI) 流程，并考虑到以下几点：
- 开发人员拥有数据的本地副本来运行开发代码
- 能够将数据库结构回滚到以前的变更集
- 能够将新功能架构更改与架构设计修复更改分开
- 能够在本地修改数据库结构进行测试
初始概念
我已经使用 SVN 和 LiquiBase 在下面勾勒了一个过程，尽管它完全删除了#4.
- 从主干创建一个“开发”分支
- 中央“开发”数据库服务器从“开发”分支运行
- 本地开发者被设置为开发分支的奴隶（
#1如上提供）- liquibase 变更集定期提交到开发分支，该分支执行提交后挂钩以更新中央开发数据库（这将渗透到作为该开发服务器的从属运行的本地机器）（liquibase
#2上面提供）- 当功能或架构修复准备好进行 QA 时，DBA (me) 会将相应的更改从开发分支合并到主干中。此行为将创建一个 sql 脚本以应用于临时数据库服务器。
- 临时服务器应该反映 TRUNK，它应该具有与生产相同的结构，加上 QA 中的更改
- 在临时服务器上执行 sql 脚本后，对更改进行一些 QA。
- 如果一切看起来不错，标记结构。这将生成由 DBA 在生产中手动运行的 .sql 脚本（如果需要，可用于非高峰时间）
这个过程要求所有开发人员都运行同一个“开发”分支，这意味着在任何给定时间只有一个版本的数据库模式（不确定我是否想要这个）。
这也意味着对架构的任何更改都无法在本地进行测试，如果做得不好，可能会影响其他开发人员。在我们的环境中，开发人员可能会添加新表，但很少修改现有结构。作为 DBA，设计修复由我完成。但是无法在本地测试修复是我最大的问题。
如何调整上述流程以允许本地开发，同时仍保持相对最新的数据副本（如我提议的流程中的复制所提供的那样）？我不要求数据是最新的，甚至是最后一周。
我想了解敏捷软件开发方法/原则/模式是否也适用于 SQL 编程。如果是，从哪里开始学习这个的好地方？是否有针对 SQL 上下文中的敏捷开发的文章或书籍？
我正在寻找有关如何为开发团队使用的数据库设置事务日志的建议。这些数据库是短暂的，因为我们从不关心硬件/软件故障时的数据恢复。相反，每次开发人员开始一项任务时，他们都会创建一个新数据库并从头开始填充数据，因此他们也会在硬件出现故障时这样做。另一个用例是自动化测试，其中为每次测试运行创建一个新数据库。
目前，由于开发人员的使用模式（测试不同类型的查询，频繁的数据批量加载），日志增长了很多，而且更多的是障碍而不是帮助。我们已经看到这样的情况：在开发人员的工作仅一个小时后，日志就开始占用 0.5 TB，迫使他们手动截断日志。由于我们不想在自动化测试期间手动截断日志，我们需要为它们分配更大的机器。我怀疑需要更多 I/O，从而减慢操作速度。
我可以在 SQL Server 文档和其他材料中找到的任何建议都适用于生产服务器并专注于数据恢复，这与我正在寻找的完全相反。
当数据恢复无关紧要，而不是操作的难易性、资源使用和原始速度更受关注时，有关配置 SQL Server 的事务日志的一些好的做法是什么？
我推迟问这个问题有一段时间了，因为在没有文字墙的情况下很难概括我们的情况和挑战，但情况越来越糟，所以我会尽力而为。我正在寻求一些帮助，以改进我们开发和管理应用程序数据库和开发人员环境的方式，特别是在跨环境的数据库依赖项方面。
我们是一家拥有大量遗留代码的中型公司。为了了解我们当前的应用程序数据库是什么样子，这里有一些大致的数字：50GB、450 个表、200 个视图和 400 个存储过程。此外，我们的生产服务器运行大约 15 个数据库，其中大部分需要或被我们的应用程序数据库需要。
澄清一下：当我说“需要”时，我指的是不会编译/将编译但不会在没有依赖项的情况下运行的数据库对象。这些对象的示例是链接服务器和复制订阅等服务器对象，或存储过程和视图等数据库对象。
在过去的一年中，我们对开发和部署数据库的方式进行了重大改进。迄今为止的改进包括引入专用开发人员环境、（几乎）所有数据库代码的版本控制、从 Git（基于触发器）自动部署以及向 SQL Server 集群的过渡。
我们正在努力解决的问题是如何处理从我们的应用程序数据库到其他数据库的依赖关系，而我似乎找不到合适的资源。这些依赖关系分为两个不同的挑战：
1. 同一台服务器上的数据库
目前来说，我们的应用数据库依赖于同一台服务器上的 5 个数据库。这些是具有单独存储库、部署管道、库和 Web 项目的数据库。在引导开发人员环境时，我们必须注意以特定顺序创建这些环境，以便成功应用 DDL 和 DML 脚本，以免我们面临依赖错误。仅此过程就引起了很多头痛。事实上，它引起了如此多的头痛，以至于我们的一些开发人员干脆放弃了本地开发人员环境，并在共享数据库中进行所有开发。
2. 远程服务器上的数据库只能用于生产
在我们的生产环境中，我们从少数远程 SQL Server 实例导入数据。其中一些数据是使用存储过程导入的，这些存储过程使用链接服务器对象引用远程服务器。为了运行存储过程，链接服务器对象需要存在。为了使链接服务器对象“成功”存在，它引用的远程服务器必须是可访问的。远程服务器只能从我们的生产服务器访问（这是正确的），但这会导致我们的存储过程在部署期间无法正确编译。
在“持续交付”一书中，作者 Dave Farley 强调，在真正的持续集成中，组装和运行项目所需的每一个资源都应该驻留在其存储库中。此外，他还指定每个环境都应该相同（凭据和连接字符串等配置除外）。我们的应用程序不满足这些原则，我什至不确定这样做是否可行。
我们的工具
感觉就像我在这里错过了一些核心架构原则。我们可以做些什么来缓解这些问题？也欢迎对相关文献提出建议。
sql-server best-practices development continuous-integration
我想要做的是安排将数据从我的生产数据库复制到我的开发/测试数据库。
开发/测试数据库在架构方面将比生产数据库更新，但生产数据库具有当前数据。我有点困惑，因为我需要针对生产规模数据测试我的数据库更改，拥有当前数据会非常有帮助。
我在 SQL Server 2008 R2 Standard 上用于生产和开发环境；有没有一种方法可以在我的开发服务器上创建一个作业，以只读方式从我的生产数据库中“吸取”数据？我想要一个脚本，可以批量复制表数据，忽略丢失的列并忽略目标表中的任何约束。一个为一张表执行此操作的脚本是我真正需要的，我可以修改它以适合我的表并复制它以运行我的所有表。我遇到的问题是发现任何与此类似的东西。
这是对我最后一个相同性质的问题的跟进；从那以后，我将我的数据库纳入了源代码管理，而且我更喜欢它。问题是我的开发服务器上仍然面临陈旧的数据问题，所以我想找到一种安排更新的方法。
我愿意采用其他方法来实现这一点，但它必须是我可以按计划运行的东西，并且我可以使用记事本和/或 SSMS 或标准版 SQL Server 提供的其他工具构建。