別の質問です。
テーブルを広くする方が良いですかvertically partition（私の場合、ログインの詳細をアドレス、個人などのユーザーの詳細から分割することを考えています）、design stageデータを取得して実行した後、そのままにしてパーティションに分割する方がよいprofilingですか？
答えは明らかなようですが、テーブルを行分割すると、ユーザーモデルを書き直す追加の作業が発生するのではないかと心配しています。頻繁にアクセスされるログインの詳細を、より静的な個人の詳細から分割することは合理的です。
どのように進めるかについて、経験に裏打ちされたアドバイスを持っている人はいますか:)? 前もって感謝します。
時期尚早の最適化は...
列を別のテーブルに分割することには欠点があります。
一方で、それを行うことでパフォーマンスが向上するかどうかは、せいぜい疑わしいです。事前に証明できない限り (ランダム データを使用して 1,000 万レコードのテーブルを作成し、いくつかのクエリを実行するのは簡単なことではありません)、私はそうしません。カプセル化と SELECT * の回避に関する Doug Kress の提案は正しい方法です。
これを行う唯一の理由は、単一テーブルの設計が正規化されておらず、正規化がテーブルの分割を意味する場合です。
単一のテーブルとして保持する方が良いと思いますが、後でリファクタリングしやすいように、データへのアクセスを可能な限りカプセル化します。
データにアクセスするときは、クエリで必要な情報のみを収集してください (「SELECT *」は避けてください)。
そうは言っても、テーブルと共に保存されたデータが適切に正規化されていることを確認してください。たとえば、ユーザーの複数のアドレスを保存したい場合があります。その場合は、別のテーブルに配置する必要があります。