shell
1rails generate model User name:string
みたいな事したんですが
model/user.rb
にはフィールドの定義が無く、
db/migrate/*
に定義があるようです。
Djangoではmodelにフィールドを定義するだけでマイグレーションが生成されていたので面食らいました。
Railsだと設計思想が違うのでしょうか?
Djangoのmodel→migration→dbが分かり易いと思うのですが、Railsはmodelとは別でmigration→dbになっていますか?
そうしている目的はなんですか?
Railsでmodelにvalidationをつけてdbにも制約をつけたい時はmodelとschemaの両方をわざわざ修正するのですか?
Django方式の方がmodelの修正だけで済んで良くないですか?
他の言語、フレームワークではこの辺どうなっているのかも知りたいです。
Active Record マイグレーション | Rails ガイド
7 Active Recordと参照整合性
Active Recordは、知的に動作すべきはモデルであり、データベースではないというコンセプトに基づいています。そして実際、トリガーや制約などの高度なデータベース機能はそれほど使用されていません。
validates :foreign_key, uniqueness: trueのようなデータベース検証機能は、データ整合性の強制をモデルが行っている1つの例です。モデルに関連付けの:dependentオプションを指定すると、親オブジェクトが削除されたときに子オブジェクトも自動的に削除されます。アプリケーションレベルで実行される他のものと同様、モデルのこうした機能だけでは参照整合性を維持できないため、データベースの外部キー制約を使用して参照整合性を増大させる開発者もいます。
Active Recordだけではこうした外部機能を扱うツールをすべて提供することはできませんが、executeメソッドを使用して任意のSQLを実行することができます。
なぜ?
知的に動作すべきはモデルであり、データベースではないというコンセプト
ちなみにDjangoにはdb→modelをするためのコマンドもあります。
これで既存のdbに対応する事もできます。
アプリに合わせてdbを作る方が多いとすればDjango方式の方が良くないですか?
モデル | Django documentation | Django
モデルは、データに関する唯一かつ決定的な情報源です。あなたが保持するデータが必要とするフィールドとその動作を定義します。一般的に、各モデルは単一のデータベースのテーブルに対応付けられます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2019/01/20 15:05
2019/01/20 22:10 編集
2019/01/21 08:02
退会済みユーザー
2019/01/21 16:14