0

私は新しい Rails プロジェクトを開始していますが、データベースに関してはどうすればよいのだろうかと考えています。移行の使用をスキップしてデータベース スクリプトを Rails プロジェクトとは別にしておくべきですか、それとも移行を使用するべきですか? データベースを「手動で」作成することで、より適切に制御できるようになりませんか? それはそれがどのように行われるべきですか？

4

5 に答える 5

2

データベースの作成は、Rails を介して行う必要があります。これは、環境ごとにほとんどすべての設定が行われるためです。

移行に関しては、Rails コア チームは、postgresql から mysql、さらには oracle に至るまで、さまざまなデータベースすべてと互換性のある移行を実現するために多大な努力を払いました。独自のテーブルを作成するよりもはるかに簡単に移行を使用して多くの操作を実行できますが、独自の SQL をミックスに追加する柔軟性も提供されます。

Postgresql データベースの HSTORE の拡張機能を作成するこの移行を見てください。

class SetupHstore < ActiveRecord::Migration
  def up
    execute "CREATE EXTENSION IF NOT EXISTS hstore;"
  end

  def down
    execute "DROP EXTENSION IF EXISTS hstore;"
  end
end

これは、移行から必要なコマンドをほとんど実行できることを意味します。Rails の移行を使用すると、移行を元に戻すアップとダウンの方法を追加することで、移行をロールバックする柔軟性が得られることに注意してください。移行でできることはたくさんあります。

また、Rails では、移行を Ruby としてダンプするか、Ruby では実現できない HSTORE などの SQL としてダンプするかを選択できます。このオプションは、application.rb構成の下のファイルの下にあります。

最後に、Rails を使用する場合は、Rails が提供するすべてのものを使用して開発を容易にすることもできます。

データベースを手動で作成する前に、Rails の移行に関するガイドを読んで、それらについてより多くの洞察を得る必要があります。

Rails の移行

于 2013-01-18T14:10:06.120 に答える
1

移行を使用する必要があると思います。コードとデータベースが「同期」していることを確認し、古いテーブルでコードを実行しようとしないようにします。

たとえば、アプリの新しいバージョンを本番環境にデプロイし、移行を使用しない場合、データベースで作業を 2 回行う必要があります: 開発時と本番時です。そして、ステージング環境、さらに多くの作業をしましょう。

もう1つの利点は、移行により、開発データベースを古い段階にすばやく「変換」できることです（私の場合、この機能が時々必要です）。

または、プロジェクトに適用できる場合は、MongoDB のようなスキーマのないデータベースを使用してください。そこでは、コード内でモデルを定義でき、移​​行について心配する必要はありません。ただし、本番環境では注意してください: ある列から別の列にデータを移行する必要があるかもしれません ;)

于 2013-01-18T14:00:50.423 に答える
1

データベース移行ファイルを手動で作成することは、レールの観点からは良い考えではありません。多くの機能を備えた宝石があり、宝石と同じ機能を提供する独自のロジックを実装しているようなものです。

これには時間がかかるだけでなく、後で更新を行う場合、移行のバージョン管理とスキーマの読み込みで問題が発生する可能性があります。

トリックは、次のコマンドで移行、足場をすばやく作成することです。

rails g scaffold scaffold_name index create name:string

これにより、上記のようにコマンドラインで指定した内容に従って足場が作成され、 で足場が作成され、scaffold_name2 つのメソッドindexと 文字列としてcreateで 1 つのフィールドが作成nameされます。

同様に、migration を使用して 1 つのコマンド ラインで列を追加できます。

   rails g migration add_field_name_to_table_name email:string

または、移行で不要な列を削除します。

rails g migration remove_field_name_from_table_name email:string

次の方法で、移行を以前のものにロールバックすることもできます。

rake db:rollbackあなたを一歩戻します

以下を使用して、任意のバージョンに移行できます。

rake db:migrate VERSION = "434483468726583"「434483468726583」は、移行先の移行バージョン番号です。

同様に、 rails migrationsを操作するコマンドはたくさんあります。

全体として、移行で必要なものは何でも、コマンドで簡単に取得できます。

于 2013-01-18T14:03:15.120 に答える
1

移行は、DB スクリプトを置き換えるためにあります。それらは管理が容易であり、相互運用性があるためです。データベースをさらに構成する場合は、個別に管理するスクリプトにコードを追加できますが、これは、使用しているデータベース システムに固有のことを行いたい場合にのみ役立ち、移行ではそれらのケースがカバーされません。

于 2013-01-18T14:06:12.410 に答える
1

Rails マイグレーションは、データベースの構造を変更するタスクです。つまり、スキーマを変更します。移行は、リレーショナル データベースの基礎となる構造を強制するのに最適であり、開始するときや他の人と作業するときに使用することをお勧めします。ただし、多くの制限と欠点があることに注意してください。たとえば、モデルで検証を作成する場合、これらの検証がデータベース レベルで適用されず、データの整合性がアプリケーション レベルでのみ維持されることがあります。

時間の経過とともに、アプリケーションと製品 (ビジネス ロジック) が進化するにつれて、モデルに多くの変更を加えることになります。移行がタイムスタンプで経時的に追跡されることを考えると、比較的大規模なチームで作業しているときに、適切なタイミングで適切な順序で移行が本番環境に適用されるようにするのは非常に困難です。

MongoDB などの非リレーショナル データベースは、スキーマの柔軟性を考慮してモデルの進化を取り入れています。たとえば、モデルにフィールドを追加する場合、移行を実行してデータベース構造を変更する必要はなく、そのフィールドにデータを保存するだけで済みます。ほとんどの人は、MongoDB は「スキーマレス」であると言いますが、MongoDB は「スキーマの柔軟性」を備えていると言う方が正確です。MongoDB を使用してモデルを定義するためのMongoid gem を確認してください。アプリケーションが探索的で、時間の経過とともに大幅に変更される可能性がある場合は、MongoDB と Mongoid を使用する価値があります。

于 2013-01-18T16:50:16.733 に答える