ruby-on-rails - Railsのアセットの単一テーブル継承の長所と短所

Question

私はファイルアップロードの宝石を見ていますが、すべてのアセットを単一の「アセット」テーブルに配置し、STIを使用してそれらをサブクラス化する傾向があるようです。、、などのようImageAssetに。VideoAssetAudioAsset

Railsは初めてで、STIを使用したことはありません。以前は、images別のテーブルを作成していました。確かに、いくつかの列を共有する可能性がありますが、いくつかの異なる列もあると思います（サンプルレートは画像には適用されません。たとえば）videosaudios

これらすべてを1つの「アセット」テーブルに詰め込むことの長所：すべてのアセットに対してクエリを実行するのが簡単です。短所：テーブルはより速く大きくなります。それが問題である場合、私は常に「タイプ」列をシャーディングできると思います。また、画像の行などでは、音声のみの列がすべてnullになると予想されます。

私のアプリ全体はアセットに基づいているので、決定を下す前に、長所と短所があることを確認したいと思います。誰かがSTI資産を作って後悔したことがありますか？誰かがそれをして後悔していませんか（大量の資産のために）？ここでは、CTI（クラステーブル継承）がより良いソリューションになるでしょうか？

Answer 1

STIを使用することの最大の短所の1つは、STIのすべてのモデル間で共有されていない（そしてそれは同じことを意味する）列をテーブルに追加した場合、あなたはただ吹き飛ばされたということですそこにデータの整合性があります。

（リレーショナル）データベースのヌルフィールドは、一般に、解決するよりも多くの問題を引き起こすものです。

私はこれに数回噛まれてきましたが、STI関係のクラスが独自のサブクラスを持ち始め、それがテーブルにさらに列を追加するようになると、特にイライラします。

この構造をできるだけ良くしたいのであれば、レールで動作させるのは少し難しいかもしれませんが、CTIの方がはるかに優れた代替手段だと思います。少なくともSTIよりもかなりトリッキーです。

頭のてっぺんに、STIが実際に合理的である可能性がある1つのシナリオを考えることができます。それは、トランザクションモデル（たとえば、銀行口座からの入出金など）を扱っている場合です。このような場合、トランザクションの「方向」を除けば、両方のモデルは基本的に同じです。

STIはラピッドプロトタイピングに「適している」と主張することもできます。何かをすばやくまとめて、それがまったく機能するかどうかを確認したい場合は、STIを使用できますが、列を追加し始めるとすぐに機能しなくなります。関係にあるすべてのモデルに意味がある場合は、おそらくそれをCTIまたは他の何かにリファクタリングする必要があります。