私はMySQLにデータベースERD connectionsを持っています。著者が記事を投稿できるシンプルなブログアプリケーションです。私は自分のデータベースを設計するベストプラクティスを知りたいと思います。私はpostとpost_bodyテーブルを持っていて、post_bodyにはたくさんのデータが入っている可能性があるので、それらを分けました。私は記事を一覧表示するために使用するので、この列はたった数回使用しますが、記事全体を表示するには投稿の名前をクリックする以外のコンテンツは表示されません。だから私はその分離がパフォーマンスにとって良いと思った。または私は間違っていると私はこれらのテーブルをマージする必要がありますか？パフォーマンスを節約するために大量のデータを別のテーブルに入れる必要があります
ほとんどのデータベースでは、列の位置は問題にはなりません。場合によっては、データタイプを介してデータ管理をヒントできます。 LARGE TEXT型はほとんどの場合テキスト索引付けされません（または部分的にのみ索引付けされます）。実際には別のファイルに格納されます。
あなたが説明した最適化は、RDBMSが理にかなっている場合には既に行われており、希望よりも効率的かつ透過的な方法で実行されます。非常に特殊な状況を除いて、それだけを残しておくほうが良いです。
実際に行う必要があるのは、行の場所の作業です。 MySQLでは、パーティション分割によって大きなテーブルに取り組むかもしれません。ただし、これを実行する前に、実行しているクエリを検討し、それに応じてインデックスを作成する必要があります。
高度な正規化（「more tables」）が良好で清潔な状況があります。これらの1対1のリレーションシップのいずれかが将来的に1対多または多対多になる可能性がある場合、マルチテーブル・データベースはより柔軟になります。たとえば、いくつかの顧客に複数のアドレスを格納する必要がある場合は、顧客テーブルとアドレステーブルを持つ方が簡単です。
私はこれを数回遭遇しました。考慮すべき事項がいくつかあります。
INDEXテーブルを取得できないため、必要な行を決定する前に追加のメタ列をフェッチしてチェックする必要がありますか？どちらも「私は必要のないかさばる体に絡みついていますか？ 「はい」の場合、「垂直パーティショニング」がになることをお勧めします。
ご使用の製品の導入が早い場合は、「KISS」をお勧めします。これは、必要と判断するまで垂直パーティションの複雑さを気にしないでください。
別の考慮事項は、
LEFT JOINを行うにつながる。）をあなたがそれを行うことを決定した場合...（あなたが使用するべきではありません）のMyISAMでは
CREATE TABLE main (
id ... PRIMARY KEY -- perhaps AUTO_INCREMENT
)
CREATE TABLE bulky_stuff(
id ... PRIMARY KEY -- not AUTO_INCREMENT, but value matches `main.id`
body MEDIUMTEXT NOT NULL ...
)
を、垂直分割をしばしば有用です。 InnoDBでは、通常、そのエンジンが大量のカラムを別々のブロックに置く方法があるため、あまり有用ではありません。ROW_FORMATをおそらくDYNAMICに変更すると、より良い（つまり、より単純な）解決策になる可能性があります。