当谈到数据库设计时，如何成为敏捷？
“敏捷宣言”：
我们遵循以下原则:欢迎需求的变化，即使是在开发的后期。敏捷过程利用变化为客户的竞争优势。
我有一个需求，我们在多个不同数据源中与多个合作伙伴团队进行跨数据库连接。有些是传统的RDMBS，有些是柱状的，其中一种是API而不是数据库，因为安全原因(所以我不能对它运行任意的SELECT ... JOIN )。
我们的解决方案是针对各种源设置ETL工作，并尝试在一个地方获取相关数据的快照，并使用这些本地表进行交叉db连接，并最终生成报告。
问题是，如果我需要使用某个新列作为连接键(引入了一个新的数据源)，或者如果有人问了一个新的业务问题，而且我还没有提取数据，那么我需要修改模式，然后重新运行所有提取的内容，在某些情况下更改转换中的业务计算，这需要花费几个小时，并且需要大量的操作开销。
我一直希望需求不会不断变化，但老实说，希望不是敏捷--我应该能够动态地回答更多的业务问题。敏捷的另一部分是，PM应该尽可能早地计划这些变化--这就是我的流程崩溃的地方吗？或者，如何构造数据流和相关流程，使其与其他类型的代码一样敏捷？
回答 2
Software Engineering用户
发布于 2016-09-01 17:31:36
我不认为这是关于数据库设计的敏捷。您可以从这个问题中删除数据库，并将其替换为SOAP或REST接口，或任何涉及多个系统通信的内容。
这里的核心问题是“敏捷对于多个团队开发多个必须协同工作的产品有什么看法？”或者“我们如何管理超出我们控制范围的变化？”
和往常一样，敏捷宣言说的是团队做什么，而不是怎么做。敏捷是一种哲学，而不是一种特定的技术。碰巧的是，我们已经磨练了一些技巧来管理您正在处理的复杂性。
一句话:自动化。
当接口发生变化时，将进行手动更改和调整。尽可能多地自动化。可能会将配置文件中的某些字段链接起来，并使用自动化的过程来构建实际移动数据的代码。然后，另一个自动化过程将数据通过系统移动。
我参与的一个项目也有类似的设置，其中数据通过web服务移动到数据库中。由于接口在开发的后期就发生了变化，所以我习惯了插入新的WSDL，更新DAO的配置，添加一行代码来移动数据，然后运行自动化的构建过程。它将生成代码，创建安装程序，安装应用程序，并将数据从一端移动到另一端，并验证按预期将数据推入web服务的数据库。
关于这些过程的工作时间:听起来像是一夜之间的过程的好候选人。
你真的没什么别的办法，因为试图让多个团队(可能是由一份薪水比一年多赚的利益相关者)达成共识比放养猫更糟糕。根据我的经验，在这些情况下，项目经理是相当无用的。他们往往坐在一起争论，而我的时间花在自动化的过程和节省时间。
Software Engineering用户
发布于 2016-09-01 17:34:40
在与@Thomas Owens聊天时讨论了这一点。
我们得出的结论是，如果回填是常见的，而列更改是常见的，那么用户说明是：
我们需要有适当的工具来快速响应不断变化的需求，并以一种不会占用开发人员大量时间的方式进行回填。
回填的实际运行时间不是问题，问题是我的时间都是手工完成的。解决方案是交付满足我所处环境要求的工作软件，换句话说，尽可能多地自动化这种数据维护。
https://softwareengineering.stackexchange.com/questions/329938
复制相似问题
腾讯云开发者
