データベースに4種類のオブジェクトをデータベースに格納する必要があります。これらのオブジェクトには同じ属性があります。オブジェクトの種類ごとに1つのテーブル、または複数の列を持つ単一のテーブルです。
これらのオブジェクトを格納するテーブルを使用して、オブジェクトの種類を識別する列を追加することはできますが、オブジェクトをたくさん格納する必要があります（> 1,000,000以上）。
私の質問はどのようなシナリオがパフォーマンスを改善するのが良いですか？オブジェクトの種類ごとにすべてのオブジェクトまたはテーブルを格納するテーブル。
私は、あなたがオブジェクトの唯一の四つの異なるタイプがあり、それらが同じ大きさと数についてのすべてのであれば、テーブルを壊すことはあまりないだろうSQL Server 2005または2008
を使用するつもりです。テーブルスキャンのコストを4倍に抑えることができますが、とにかくフルスキャンを実行する必要はありません。あなたはインデックスを通過し、それは問題ではありません。
4つのタイプのサイズやアクセス数がまったく違う場合は、それを分離する方がサイズが小さくなり、数が少なくなります。より頻繁に照会されるもの。しかし、これは、インデックスを使用するときのパフォーマンスに影響を与える大きな歪みである必要があります。
テーブルを分割すると、複数のタイプ間でクエリを実行したり、後から新しいタイプを追加するのが難しくなります。
一方、複数のタイプにまたがってクエリを実行する必要がなくなり、その名前がすべてのオブジェクトタイプで一意でない場合は、それらを単一のテーブルに保持する必要はありません。
「タイプ」の列がないことがわかりました。 4つのタイプを区別する必要がある場合は、おそらく1つは必要です。それとも名前を見るだけでこれを行うことができますか？
名前はプライマリキーですか？ テーブルサイズは、主キー検索のパフォーマンスにごくわずかな影響しか与えません。
純粋なボリュームは、類似のオブジェクトを別のテーブルに分割する良い理由ではありません。パフォーマンス、インデックス作成、テーブルの分割を改善する他の方法があります。
テーブルに型の列を追加すると、メンテナンスとクエリが簡単になります。
異なるタイプのオブジェクトの名前とIDを持つ1つのマスタールックアップテーブルを作成します。次に、名前の代わりにidを持つ従属テーブルを作成します。 1つのテーブルを持ち、オブジェクトタイプ（id）に応じて水平に分割することができます。
名前の代わりに整数IDを持つことの利点は、あなたが大幅にクエリをスピードアップするであろうと同じにインデックスを作成することができるということです（特別テーブルのサイズはあなたが言及するものである）あなたの質問はパフォーマンスであり、利便性ではありませんでした。 したがって、それぞれ別のテーブルが最適です。これにより、各索引のレコード数が減り、基本的に正しい表を選択してフィルタを実行しています。
オブジェクトは真に同等か、偶然に似ていますか？それらを一括して扱うことによって、あなたは正当な前提をしているかもしれません。後で、オブジェクトタイプの1つに他の属性が必要ない追加の属性が必要であると判断した場合は、かなりの再処理タスクが必要になるか、または少量の行で終了する可能性があります。
また、「説明」と呼ばれる分野は疑いがあります。モデリングの兆しを示す悪い匂いです。それは欠けている属性すべてのためのキャッチとして使用される傾向があります。私はモデリングを主張しませんが、多くの有用な構造がこのように埋もれる可能性があります。たとえば、「地域の承認」に基づいて処理を行った商品データベースに機能を追加しなければならなかったのです。しかし、領土の承認属性はありませんでしたか？ユーザに話した後、彼らは考案した特別なコードのシステムを使用して、記述フィールドに地域データを格納したことが明らかになりました。
いいえ、プライマリキーとして列id_objectがあります。 – VansFannel
型については、列は型と呼ばれるテーブルの外部キーになります。 – VansFannel
そしてあなたはid_objectだけで物事を調べるでしょう、と思いますか？次に、1つの大きなテーブルとプライマリキーインデックスを使用するとよいでしょう。 – Thilo