私のRailsアプリには、アセット（添付ファイル、写真、ロゴなど）を扱ういくつかのモデルがあります。私はattachment_fuを使用していますが、これまでのところ、MySQLDBに情報を格納するための3つの異なるテーブルがあります。
STIを使用し、型列を使用し、異なる継承されたクラスを使用して、すべての情報を1つのテーブルに配置した場合、パフォーマンスに違いが生じるのではないかと思います。すべてが多くの属性と特性を共有しているため、より乾燥して保守が容易になります。
しかし、何が速いのでしょうか？多くのテーブルとテーブルあたりの行数が少ないのか、それとも1つのテーブルに多くの行があるのか。それともまったく違いはありませんか？1秒あたりに多くの情報と多くのクエリを処理する必要があります。
ご意見ありがとうございます！
多くのテーブルと少ない行はおそらくより高速です。
ただし、そうする必要があるのはそのためではありません。データベースは問題ドメインをモデル化する必要があります。1つのテーブルは、多くのエンティティタイプの貧弱なモデルです。したがって、現在関心のあるエンティティタイプを表すそのテーブルのサブセットを見つけるために、多くのコードを作成することになります。
通常の、受け入れられた、クリーンなデータベースとフロントエンドクライアントコードは機能しません。これは、1つのテーブルがすべてのものであり、すべてのものがないためです。
速度が遅く、壊れやすく、アプリ全体でコードが増加し、モデルが貧弱になります。
これは、問題のドメインですべてのものがまったく同じ属性と同じ（またはおそらくリスコフの置換可能）意味を持っている場合にのみ実行してください。
それ以外の場合は、これを実行しようとしないでください。
または、そうする場合は、アプリ内のすべてのエンティティを保持するために1つの大きなマップ/ハッシュテーブル/連想配列を使用するよりも優れている理由を尋ねてください（そして多くの関数、それらのほとんどは複製、切り取りと貼り付け、そして時代遅れですswitchケースまたはRTTIを使用して、各エンティティの実際のタイプを把握します）。
確実に知る唯一の方法は、両方のアプローチを試し、パフォーマンスを測定することです。
一般的に、これらのテーブル間で結合を行っているかどうか、および行っている場合は、テーブルのインデックス作成方法によって異なります。一般的に、データベースの結合にはコストがかかるため、パフォーマンスを向上させるためにデータベーススキーマが非正規化されることがあります。これは通常、大量のデータ、つまり数百万のレコードを処理するまで発生しません。あなたはおそらくまだその問題を抱えておらず、おそらく決してそうなることはないでしょう。
行が同じ属性を持っている場合は、はい、1つのテーブルが非常に優れており、データのタイプを指定するために1つの行だけがあります。それ以外の場合は、異なるテーブルを使用して処理し、パフォーマンス、コード量、さらにはコードの信頼性も向上します。