問題タブ [vertical-partitioning]

既に 32 列あるテーブルに 64 個の新しい列を追加する必要に直面しています。例のために：

ほとんどの場合、これらの新しい列の大部分には が含まれますnull。

また、これらSELECTの 64 個の新しい列を新しいテーブルに垂直方向に分割すると、顧客からのたびに次のようになります。

分割された値を取得するには、結合に変換する必要があります (つまり、新しい列を必要としない場合にパフォーマンスが向上することはありません) 。

これは、列を分割することの 1 つの欠点です。

もう 1 つの短所は、行を 1 つだけではなく 2 つのテーブルに同時に挿入する必要があることです。

私が考えることができる最後の詐欺は、SQL Server が「 CustomersINNER JOIN 」にアクセスしたいときにいつでも実行する必要があるということです。実際には 1 つのテーブルであるテーブルを結合するための CPU と I/O の浪費は、今後も永遠に続きます。ただし、それらを分割することにした場合を除きます。

だから私の質問は：なぜ私はそれらを分割するのですか？

ほとんどがnullになる場合、64列を別のテーブルに垂直に分割することに価値はありますか? Null はほとんどスペースを占有しません....

長所は何ですか？

編集：なぜ私はパーティショニングを考えているのですか? テーブル内の列数を 3 倍にするのは、ほとんどが null データです。きっと悪いに違いない！

かなり長いリース申請フォームを、PHP経由でPostgreSQLデータベースに送信するためのWebアプリケーションに変換します。

私は「痛むまで正規化し、次に機能するまで非正規化する」という格言を守ります（Attr：SQLMenace）が、飛び込むと集合意識を利用することになりました。

紙のフォームは現在次のようになっています： http ：//www.borgermanagement.com/forms/commercialApplication.pdf （実際のフォームではありませんが閉じる）

多くのデータは必須であり、後日完了するために部分的に完了したアプリケーションを保存するオプションを使用して、いくつかのビューで送信されます。提出された申請書は承認のために審査されます（できればPDFと同様の1つのビューで）。今後、データの詳細な分析はあまり行われない可能性があります。

この場合、データをどのように構成しますか？正規化するかどうか？垂直に分割するかどうか？

最近、テーブルに LastUpdate 列を追加し、それを更新し続けるためのトリガーを追加しました。私が一緒に働いている人を侮辱しないように議論したくない理由により、LastUpdated 列はめったに使用されないため、垂直分割を使用してその 1 つの列を別のテーブルに格納する必要があると判断されました。テーブルにはすでに 43 列が含まれているため、これは少し過剰に思えます。彼らが物事をやりすぎていることを支持してくれるかもしれないという提案を誰かが持っていますか? それとも、彼らは実際に正しいですか？

編集 (9/29)
申し訳ありませんが、私は恐ろしい人です! 「彼ら」はテーブルを垂直に分割しないことに決めたので、この質問に戻るのを忘れていました。私が始めたことを完了するために...

@JNK、テーブルにはId列のみを含むPKのみがあります（これは「アイデンティティ」です）。

@elevener、ご意見ありがとうございます。これは、「彼ら」が、このテーブルまたは他のテーブルで垂直分割を進める必要があると判断した場合に役立ちます。

私は4つのテーブルを持っています

そして、別のテーブルEが（Dではなく）BまたはCだけを参照できるようにしたいと思います。何を書くことができますか

？

私は現在、多くのユーザー フィールド (+/- 80) を処理する必要があるプロジェクトに取り組んでいます。私の最初のアプローチは、ユーザー テーブルを 4 つのテーブル (主な情報、管理情報、銀行情報、統計情報) に垂直に分割することでした (今でもそうです)。3 つの余分なテーブル行の ID は、メイン テーブルの自動インクリメント ID を参照します。

私の質問は次のとおりです。

1. そうすることは適切ですか？
2. 私が関連付けを行った方法では、Doctrine は 1 つのオブジェクトを一度にデータベースにフラッシュすることができないようです:

タイプ MyVendor\User\UserBundle\Entity\UsersInfosBank のエンティティには、フィールド 'id_user' に割り当てられた ID がありません。このエンティティの識別子生成戦略では、EntityManager#persist() が呼び出される前に ID フィールドに入力する必要があります。代わりに自動生成された識別子が必要な場合は、それに応じてメタデータ マッピングを調整する必要があります。

プロジェクトは 3 週間で本番環境に移行されるため、これらのデータを 1 つの巨大なテーブルに格納する従来の方法に戻ることができます…

****************アップデート*****************

以下のコード全体のロジック*****************

私の問題に関係のないプロパティとメソッドのほとんどを削除しました…</p>

はい、私は FOSUserBundle を使用しています ;)

ユーザーメイン

ユーザー情報管理者

ユーザー情報統計

ユーザーを作成する方法は次のとおりです（安全な管理エリアフォームを使用します）：

私はmysqlを使用しています。名前、姓、年齢、性別などの基本情報を保持するユーザーテーブルがあります。プロファイルと呼ばれる機能を提供したいと考えています。ユーザーは、勤務地、代替連絡先などの他の情報を入力します。 . これらの新しい列は固定されていません。将来、列を増やすことができます。私の知る限り、2つのアプローチがあります。

1) 必要に応じて毎回新しい列を追加します。これにより、新しく追加された列の前の行に Null エントリが配置されます。

2) すべての列 ID を列名に含む新しいテーブルを追加し、次のように、その特定の新しい列のエントリを持つ各ユーザーの構造のようなキー値を含むもう 1 つのテーブルを追加します。

表 1 : ユーザー ID | ファーストネーム | 年齢 | ....

表 2 : 列 ID | 列名 | データ・タイプ

表 3 : ユーザー ID | 列 ID | 価値

私のシナリオに適したアプローチはどれですか?