水平スキーマと垂直スキーマ
私は控えめなSQLDBAです。新たに提案されたデータベースの中心部分の設計についてアドバイスをお願いします。
ブレントオザールはこれについて何か言いたいことがありました： SQLテーブルを水平方向に構築するVS垂直方向に構築する 。ブレントまたは豊富な経験を持つ人のどちらかが、この問題に関するフィードバックや経験を私に教えてくれますか？
データベースの中央部分に関する詳細：
トランザクションレプリケーションを使用してレプリケートされます。
CDCは有効になっていますか。
ファクトベース（トランザクションベースではない）、つまり製品の概念のようなものです。
要件が発生したときに、新しいアイテムを簡単に追加できるようにしたいと考えています。水平アプローチを使用する場合、既存のテーブルにテーブルまたは列を追加する必要が常にあります。
特定の基準に基づいてすべてのエンティティ属性値テーブルを分割して、データへのアクセスの作業負荷を軽減できますか？
私は（常に変化する）システムの一部のみについてメタデータベースのシステムを使用してきました。これの利点は、データとワークフローの構成で、必要な特定の詳細を構成する必要があるたびに追加の開発を必要としないことでした。また、インデックスとパーティションを巧みに使用することで、データに簡単にアクセスできるようにしました。
この問題に関して（そして私が持っているかもしれない誤解に関して）あなたが提供しなければならないアドバイスに本当に感謝し、尊重します。
あなたの選択はどちらかまたは両方である必要はありません-あなたは両方を持つことができます。
「物理レベル」では、パフォーマンス、メンテナンス、および信頼性の理由から、一般的に水平設計を使用する方が適切です。しかし、より大きなルールは、「データとメタデータを混在させない」です。メタデータテーブルを読み取ってCREATE TABLEとALTER TABLE Foo ADD Col1を実行し、アプリ自体がデータモデルを変更できるようにする方法を知っているアプリケーションを構築することには、本質的に問題はありません。そうすれば、両方の長所を活用できます。 DMLと同じように、テーブルと列を追加することを考えてください。もちろん、これを行う場合は、スキーマが変更されたときにレプリケーションを再構成する必要があります。
上記の設計ガイダンスでは、他のテーブルの機能を説明するメタデータを含むテーブルがあることを除外していないことに注意してください（したがって、アプリはそれを操作するように構成できます）。データウェアハウスを構築する場合、これは通常、優れたアイデアです。メタデータを使用して、新しいアプリケーションコードを生成およびコンパイルすることもできます。