Railsのmodelとmigrationの関係、他のフレームワークではどうなっているのか？

Question

rails 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

モデルは、データに関する唯一かつ決定的な情報源です。あなたが保持するデータが必要とするフィールドとその動作を定義します。一般的に、各モデルは単一のデータベースのテーブルに対応付けられます。

Answer 1

設計思想については省略しますが、1点だけ。

model/user.rb

にはフィールドの定義が無く、
db/schema.rb
に定義があるようです。

Railsのモデル定義はdb/schema.rbによるものではなく、データベースを読み取って動的に生成しています。なので、Rails外で作成したテーブルをそのまま使うときも、モデルクラスを立てれば基本的なCRUDは設定なしで使えます。

Comments

[退会済みユーザー]

＞設計思想については省略しますが
省略しないでください。
一番知りたいのはそこです。
省略というからには知っているんですよね？
「省略」ではなく「わからないから書けない」でしょうか？

[maisumakun]

設計思想に関する部分は、実のところ自分も知りたいです。

質問内で明らかに間違っているところは、それと関係なく指摘すべきと判断したので指摘したまでです.

[matsuand]

正直に申し上げますが、ご質問者殿の返信コメントはやや礼儀を失した風に感じます。ひとこと謝辞があってしかるべきかと。私も全くの門外漢ではありますが、それぞれの設計方式によるもので、そのいずれかが優れている劣っているという、白黒はっきりした結論はないように思います。結論を得たいとお思いのご自身が、じっくりと取り組むところかと思います。

[退会済みユーザー]

謝辞？何に対する？
私はDjangoの方が良いと白黒はっきり判断してますよ。
自分でじっくり取り組めってなんやねん。teratailの存在意義は？
私はDjangoの設計の方が優れていると思ってるけどもしかしたらRailsの方が良いという意見もあるかもしれないから聞いてみるって使い方したら駄目なの？