このテーマについて他の人がどう思うか知りたかっただけです。私は、各ユーザーに関するかなり多くの固有の情報を含むプロジェクトを持っています。冗長性がなく、多数のユーザーが存在する場合、データを小さなテーブルに分割すると高速になりますか?
1000 個のクエリを使用してテストを試みましたが、そのうちの 1 つは 87 列で、もう 1 つはログイン情報のみが個別に保存されていました。私が得たものでは1372ミリ秒、他のものでは879ミリ秒でした。一見すると速いように見えますが、おそらく誰かが私よりも経験が豊富で、これについて彼らの見解を述べることができますか?
テストでは、「SELECT *」を使用して大小のテーブルからクエリを実行し、すべての列を返す場合、もちろん、より多くのデータを返す必要があるため、より大きなテーブルには時間がかかります。ただし、本番アプリでは、アプリケーションのクエリを対象にして、必要な列のみを返す必要があります。
各テーブルにフィルタリング対象の同じインデックスとデータがあり、それぞれが同じ選択された列を返す場合、結果セットはほぼ同時に返されるはずです。ただし、パフォーマンステストを検討する場合、この時間は非常に誤解を招く可能性があることを付け加えておきます。データベースサーバーには、継続的に変化する多くの要因があり、実行しているクエリとは関係ありませんが、実行時間に絶対的に影響を与える可能性があります。測定としての時間の代わりに、論理読み取りを調べてみてください。
設計に関する質問については、どちらの方法でも技術的には機能します。ただし、開発チームの他のメンバーを支援するために、特定のデータにアクセスする必要がある頻度を検討することをお勧めします。80％の確率でクエリされる列の20％がある場合は、それらを独自のテーブルに含めることを検討することをお勧めします。これにより、新しい開発者がチームに多大な時間を費やして、クエリしたいものを特定するためだけに、一般的に重要ではないデータの多数の列をふるいにかける必要がなくなります。
さらに、物理的な設計の観点から、コストが問題になる場合は、パフォーマンスの高いディスクドライブに頻繁にアクセスする必要がある20％のテーブルを配置し、パフォーマンスの低いディスクドライブに80％のデータを配置できます。