14

したがって、Rails の STI (単一テーブル継承) が厄介であることは誰もが知っています。データ モデルが雑然とし、データベースが最適化されていないからです。

しかし、PostgreSQL は継承を非常に美しく処理しているようです。

痛々しいほど広いテーブルと「型」列の代わりに Postgres 継承を利用しながら、Rails のきれいな STI API を取得する方法はありますか?

4

2 に答える 2

8

しかし、PostgreSQL は継承を非常に美しく処理しているようです。

本当に？マニュアルの小さな文字をよく見ましたか? 例えば：

  • 継承レベルを超えて一意の制約 (したがって主キーも) を使用することはできません。
  • 継承されたテーブルとベース テーブルへの参照は混在しません。つまり（マニュアルから大まかに引用）: capitalsextends cities。あなたのaddressテーブルは を参照したいcitiesです。できる。ただし、a 付きの no アドレスはcapital使用できます。

これら 2 つのことは、小規模な "Hello World" プロジェクト以外のあらゆる場合に非常に重要です。したがって、PostgreSQLの継承を使用して生産的なものを実装できるとは想像できません。

于 2012-04-18T17:29:04.040 に答える
5

要するに、あなたが今達成しようとしているもののためのきれいな STI API はありません。

私は実際に約1年前にそれを調べ、いくつかの理由でそれは良い考えではないという結論に達しました:

  1. PostgreSQL 固有の機能を利用したい場合は、基本的にその DB と結婚することになります。誤解しないでほしいのですが、PostgreSQL は優れた DB であり、私は何度も使用してきましたが、その DB とアプリの設計に行き詰まるでしょう。
  2. ほとんどの場合、DB 固有の機能を使い始めると、それらを手動で実装する (DB である種のコマンドを実行するか、GUI を使用する) か、db:migrate を実行するたびに呼び出さなければならないスクリプトを書くことになります。 （適切なテストを行いたい場合は、それを行う必要があります）。しばらくすると、面倒で面倒になります。
  3. ますます悩まされていることに気付いた場合は、「非常に広いテーブルと「タイプ」列」を引用すると、次のようになります 。
    • テーブルのデザインを再考し、やり直す必要があります
    • あなたのモデルは STI の良い候補ではないかもしれません
    • あなたはそれと一緒に暮らす必要があります。

ほとんどの IT の問題は、実際には次のようになります。労力と利益です。

あなたの場合、次の質問を自問する必要があります。

  • 生の SQL クエリを数秒だけ高速化できるとしたら、より良い STI 構造の実装にどれくらいの時間を費やしたいですか? もっとわかりやすい SQL クエリを書いたほうがいいのではないでしょうか? ほとんどのアプリケーションは、実際に問題になるサイズにはなりません。しかし、あなたの場合は違うかもしれません。

PS:

また、アプリで STI を構造化するための簡単なヒント: ProductCategory、CommentCategory、PhoneCategory、ClientCategory のように STI を使用する多くのモデルがあり、それらはすべて Cateogory から継承されていることがわかった場合、モデル ディレクトリ内のフォルダーにそれらを整理する傾向があります。次に、application.rbに次の行を追加します。config.autoload_paths += Dir[Rails.root.join('app', 'models', '{**/**}')]

于 2012-04-18T16:07:27.333 に答える