在开发过程中处理频繁变化的数据库模型的推荐策略是什么？

Question

在早期开发过程中，很多项目都需要确定数据库模型。这可能意味着许多SQL将不得不频繁重写。建议采取什么策略来解决这一问题？特别是当您想要开发您的应用程序，类似RAD和最终的要求是根本不被设定的？大多是玩具项目。

一个理想的场景是，在项目开始时，我根本不能编写任何SQL，只有当数据模型更加稳固时，我才能实际为项目建立数据库，并为其编写SQL。在最初的开发阶段，我只希望能够更改实体类，而不必一次又一次地更改SQL。

(对于我要问的项目，我正在使用Spring 4和一个MySQL数据库)

Answer 1

我们在当前项目中使用的技术(可能对您有用)是使用液基。所有数据库更改都通过配置文件进行，这些配置文件被签入源代码管理，并在应用程序启动时自动运行。这有助于使数据库模式与代码保持同步--每当您将最新版本拉到分支时，就会得到最新的数据库配置。如果您做的不仅仅是添加表或列，它就会变得有点麻烦，但是IME在新的系统开发过程中所做的大部分更改就是这样的。

我相信还有其他几种“代码优先”的-style ORM产品，但这是我唯一真正熟悉的产品。好吧，还有.NET实体管理器，但是由于您使用的是Spring4，所以我假设您使用的是Java。请注意，其他代码优先解决方案可能要求您在架构更改时完全删除并重新创建数据库。通常，在早期开发过程中，这不是一个问题，但在以后可能会成为一个麻烦。

Answer 2

我更喜欢在功能的垂直切片中工作，而不是将整个数据层保持不变直到结束。

许多ORM都具有数据库生成功能。它不需要复杂且支持DB模式差异，因为在开发中，您通常并不真正关心您的数据，也不介意从头开始重新创建DB。但是，当您的应用程序进入维护模式时，这可能是一个很好的资产。