想象一个操作大型分层数据集的程序。该程序将每个新的此类数据集存储在专用表中。该表是根据数据集在其中的数据类型创建的。嗯，没有什么不寻常的。这是一个微不足道的情况。但是在进化范式规则的 Play 2.0 中，我该如何进行这种安排呢？我只是无法开始思考它。
更新
事实证明，没有简单的方法。行。圆形的方式。
是否有可能：
1）让程序自己编写进化文件并自动应用它们？会不会对 Play 的理念造成一些扭曲？
2) 在单独的线程中使用另一个数据库系统并且不使用 Play 的固有数据库功能？会不会很痛？
更新 2
我正在阅读 MongoDB Casbah 文档，我非常喜欢它。我打算将它与我的 Play 应用程序一起使用。通过 Casbah 和 Play 使用 MongoDB 有什么相反的证据吗？
这是个好问题。不幸的是，没有出色的答案。
一般来说，进化是好的，当你在小组中工作时是需要的。在这种情况下，您应该切换到手动进化（不是由 Ebean 生成的，它们对您当前状态的数据很危险），并使用 create 语句将您的初始 DDL 尽可能大。
在接下来的演变中，您可以创建新表或更改现有表，但看在上帝的份上，不要尝试创建现有表 :)
我正在（或仍在）考虑的其他方法是使用 Ebean 的自动生成的 DDL（它始终假定您的数据库为空）通过一些 SQL 模式迁移工具（即 mybatis）生成差异模式，但不幸的是，这需要额外的努力。
当我不确定正确的进化语法时，我有时会使用的最后一件事是小型测试场应用程序，您可以在其中添加类似的模型并观察 Ebean 的插件将如何威胁它们。不幸的是，即使这个解决方案也不会创建适当的更改，但它比在主应用程序上测试更好。
好吧，经过更多的实验，我得出了使用 MongoDB 的结论（实际上，我不得不从各种面向文档的 DBMS 中进行选择，并决定从 MongoDB 开始）。我已经建立了一个 MongoDB 服务器，将它的 Java 驱动程序、Casbah（驱动程序的 Scala 包装器）和所有必要的依赖项合并到我的项目中，并且一切正常。无论如何都不需要 SQL 或进化范式。
而且我没有使用 Play 中与数据库一起使用的任何部分（配置文件、异常，以及那里还有什么），只是忽略了这一点，并做所有的 Mongo。
所有作品都很好！