连续创建和删除表是否表明存在体系结构缺陷？

最近，我与一位开发人员进行了讨论，该开发人员提到在程序开发过程中，他们会定期创建和删除表和列，同时使用新功能和合理的工作，并说使用敏捷开发过程是正常的。

由于我的大部分背景都是在瀑布式开发环境中进行的，所以我想知道这在敏捷开发中是否被认为是正确的，或者这可能是潜在问题的征兆，无论是程序体系结构还是遵循敏捷过程。

每天对我来说，“敏捷”越来越成为思想周到，混乱，匆忙和坐在你的裤子上的代名词。据我了解，这些东西都与敏捷方法不兼容。

拥有一个有效且可重复的敏捷过程并不容易，而且我不认为它会固有地减少要完成的工作总量，即使它很可能会带来更好的产品。

如果他们说他们没有时间“重构”数据库，那么他们可能也没有时间为数据库设置版本和迁移。他们可能没有花时间为它创建一套功能测试。当我想到一个稳固的，迈向成功的敏捷流程时，所有这些都是我想到的。

最后，敏捷只是一个词。您每天的工作将决定您是否成功。

尽管随着设计的发展而创建和删除表并不罕见，但为了确保您的数据库确实使用了所有这些表，可能需要进行一些清理。

是的，敏捷就是重构，但是如果他们现在说系统太大而无法重构，那么他们就停止做敏捷了，现在只是牛仔编程。开发团队不喜欢这样称呼，但这就是他们正在做的事情。骑在范围内拍摄任何移动的东西。

DBA会有所帮助，只需确保您拥有一个既了解开发又了解敏捷开发的DBA。您的开发团队需要控制，而不是入狱。

通常，在编程和数据库管理没有严格分开的过程中，经常创建新表和添加新列是非常正常的。一项新功能可能会创建必须放在某个地方的新数据。过于严格地尝试避免这种情况，您最终会得到一个内部平台模型。

编写良好的软件几乎不会注意到那些新的数据库对象，因此，仅由于某些表中的新列而不会中断任何操作。

另一方面，定期删除列甚至表是可疑的。一个新功能永远不需要删除表，因此这可能表明人们完全没有计划地工作。

如果您的数据库可以轻松地进行版本控制和迁移，并且您已通过测试证明变更并不会破坏事情，那么您可能已经有了一个非常敏捷的过程。

鉴于这些评论（通常是一群自称敏捷的牛仔），他们大声尖叫。快速。并将所有内容发布到thedailywtf.com，以便我们都可以享受您的恐怖。

像在StackExchange上的大多数答案一样，答案应该是“取决于”。在敏捷开发中，在实施过程中会发现需求和规范。

但是，在进行敏捷开发的情况下，如果适当地规范了关系模型，则很少需要向关系中添加新属性，给定适当的模型，新实体通常应引用较旧的实体。

由于时间限制，懒惰，无能或查询复杂，大多数开发人员不对数据库进行标准化。重新规范化要求传输现有数据，修改DAO等，这会产生风险因素。

要回答您的问题，不，在敏捷过程中这是不正常的。

它可能看起来阻止从敏捷的态度是敏捷的短迭代设计/开发/测试周期和敏捷的重点放在满足已知需求轻量级的解决方案，但为了在结构良好，能够满足新的要求最小的变化。鉴于这两件事，您可能会说，一个开发人员不知道将要发生的事情，但是知道他的更改不会以无法撤消的方式影响数据库，只需要对架构中的模式进行必要的更改即可。尽可能采用“最轻”的方式，然后每隔一段时间将几组“轻”的更改重构为更永久和稳定的内容。

话虽如此，我还没有与订阅敏捷理论和方法的开发人员一起工作，并且还认为出于任何原因，必须在模式中例行创建和删除表。敏捷并不意味着一巴掌或螺栓。如果给出的故事需要添加属于特定记录的新数据字段，则可以将该字段添加到表中。如果该更改破坏了某些内容，那么您会找出原因，并进行必要的其他更改（我认为只有很少的事情会因在要查询的数据库中添加一列而被破坏；如果确实因这种更改而被破坏，则您有更大的问题）。重构通常仅限于代码；与更改代码相比，更改模式通常是一个更复杂的过程，因此，当必须进行模式更改时，通常要格外小心，至少对项目的未来方向有所了解。必须重新构造部分或全部数据库表明设计的根本失败；敏捷并不意味着在有机地构建程序和数据结构时，没有基础架构和设计规则的“总体规划”。

现在，在敏捷中有些情况下，您现在“知道”的内容将与以后学习的内容相矛盾。假设您有一个要求，即系统必须为每个人提供一个地址。由于这是1：1的关系，并且在大多数情况下将需要数据，因此您只需在“人”表中添加“地址”字段即可。一周后，您收到一个人必须拥有多个地址的要​​求。现在是1：N关系，并且要正确建模，您必须撤消之前的更改，将字段拆分为新的Address表。这不是日常工作，特别是在高级开发人员中。有经验的开发人员将看到一个人有一个地址，在概念上将它们视为独立的，然后创建一个人表和一个地址表，将人到地址与FK引用链接到地址ID。如果关系的性质发生变化，则这样的模式更容易更改。无需创建或删除整个“宽”数据表，就可以轻松地将Person和Address之间的关系从1：1更改为1：N到N：N。

在敏捷环境下工作时，没有过多地关注前端设计，因此我认为这并不是一个大问题，当然对于第一个版本而言。

在一个有700张我从未见过的表的系统上，很难对此发表评论，它很可能需要所有这些表，但也有可能是数据库管理不够好。

即使在敏捷的情况下，对于大型系统来说，仍然仍然有个人/团队负责架构是很常见的。

如果他们经常进行此类更改（尤其是在活动应用程序中删除表和列），则似乎缺乏经验。这与他们声称要遵循的任何流程都没有关系。在开始编写代码之前，“敏捷”不是借口不坐下来思考一下您需要存储的数据及其之间的关系的借口。如果他们发现他们正在改变初始结构的10％到20％以上，那么对我来说，这就是他们要么没有考虑问题，要么他们没有太多分析需求和设计数据库的经验，因此他们也获得了一开始的很多错误。

听起来您的团队确实只是牛仔编码，但重构代码或数据库确实应该没有错。它不会丢失工作，它正在适应新近学习的现实。

我建议团队需要一个沙盒来尝试更改，进行一些测试，将其反弹给用户并决定它们是否有意义。到那时，将有意义的更改（通过适当的回归测试）集成到您的模式中应该没问题。

敏捷是关于编码的，数据库不是编码。更改数据库应被视为重塑房屋。人们以某种​​方式相信敏捷方法现在要在以后计划，这是完全不正确的。即使采用敏捷方法，也需要花时间进行规划，尤其是对于与数据库设计同样重要的事情。

我的上一份工作是在这样的团队中。使用敏捷过程时，需求会发生变化。有时，更改意味着现有实体需要一个新属性，从而导致现有表中有一个新列，或者需要一个全新的实体，从而导致一个新表与现有表的关系。这些变化伴随着领土而来，不能仅仅因为您不想触碰模式而被忽略。从一个数据库版本迁移到下一个数据库版本并进行适当的单元测试时，要保持数据的完整性来确定成功。

只是尽量不要对模式进行不必要的更改。例如，如果某个功能需要创建一个新表，则在签入表并将其部署到测试环境之前，请确保对表的定义满意。数据迁移之后，必须撤消对数据库架构的更改可能会很痛苦。