我需要在migrations+scaffold或不可知的数据库建模之间进行选择吗？

Question

我有一个数据库，我必须用它来构建我的应用程序。它是由其他人建模的，但是它遵循rails惯例。我可以很容易地映射它与活动记录。

我可以使用迁移对数据库进行深刻的更改吗?还是应该继续使用图表建模并导出它？

在以前建模的数据库之上使用迁移或脚手架是一个很好的实践吗？

因为在脚手架之后，我通常会遇到一些错误消息，比如有一个迁移，试图创建一个已经存在的表。当我删除有问题的迁移时，情况只会变得更糟。

用于这个问题:不可知的方法使用任何外部建模工具(GUI、SGBD工具).

Answer 1

你基本上可以走任何一条路。您选择哪一个将取决于您的开发风格。

如果您使用scrum/敏捷，那么它为以后的迁移提供了一个强有力的理由。

迁移基本上也是rails整体蓝图的一部分，也是使rails在开发过程中工作得非常好的部分之一。迁移的一个巨大好处是，您可以用您想要的任何数据库创建应用程序，这在将其移动到另一个提供者*时是很棒的。但是，对于未完全使用迁移完成的db，需要执行两个步骤--在开始迁移时创建初始的db‘直至’，然后继续使用它们。

迁移和脚手架在现有数据库上是很好的。迁移正在添加(或删除)新的db内容，而脚手架可以创建新的db记录(当迁移运行时)，它们确实有助于遵循rails标准，并创建常规的named.stub测试文件。

当第一次习惯于迁移时，错误消息和语法非常令人恼火，但随着时间的推移，这是其中之一。rails中有很多类似的东西，比如学习所有的比特，并允许出现奇怪的错误消息。

在这方面有帮助的工具是mySQL工作台(obv )。对于mysql)和rubyMine IDE，每个工具都可以让您查看现有的数据库，甚至可以使用mySQL的实际表与使用rails模型中的信息进行比较。

*然而，移动一个实时应用程序的实际数据是另一回事。