私は、GEDCOM 準拠の家系図を持つソーシャル ネットワーキング サイトに取り組んでいます。ユーザープロファイルに水平または垂直のデータベース構造を使用するかどうかを決定する必要があります。ですから、水平データベース構造を使用する場合と垂直データベース構造を使用する場合に誰かが答えられるかどうか知りたいです。
フィールドが決まっていないショッピングサイトについては、縦型のデータベース構造を使用する必要があるという答えが見つかりました。しかし、家系図サイトに何を使うべきか迷っています。縦と横のどちらを使うべきですか？
Mysql、Ms sql、Sqlite、Postgresql、Oracle などのリレーショナル データベースをストレージに使用していると思いますか?
Gedcom は情報交換の標準であるため、列数を把握できます。将来、標準が新しいプロパティで拡張される可能性がありますが、おそらく多くの新しいプロパティにはならないでしょう。いくつかの新しい列を使用してテーブルを簡単に拡張できます。
エンティティ属性値システム (垂直テーブル) ではなく、「水平」テーブルを使用します。垂直テーブル システムは遅くなる傾向があります。これらは適切にインデックスを作成できず、クエリ オプティマイザーを混乱させます。
ユーザーが目の色(u)rやお気に入りの色(u)rなどのプロファイルで新しいプロパティを定義できるようになると、話は別です。それらのプロファイルをどの程度柔軟にしたいですか?
垂直データベースは、デタウェアハウジングおよび読み取り/専用レポートに最適です。通常、それらを一晩で再生成します。それらの書き込みパフォーマンスは通常非常に悪いですが、SELECTは10〜100倍高速です。
垂直データベースを使用する一般的なシナリオは、データの（毎日の）スナップショットを作成し、それに対してクエリを実行する場合のOLAPレポートです。ほとんどの利点は、比較的少数のフィールドのみを要求するクエリから得られます。たとえば、幅の広いテーブルと大きなテーブルから少数のフィールドのみを選択する場合などです。数百万のレコードに対するこのようなクエリクエリ（たとえば、SUM / COUNT / AVGの計算）には、1〜2秒しかかかりません。
あなたのケースは、垂直データベースの適切な候補ではないようです。
私は tuinstoel に同意します。垂直テーブル/EAV システムは遅いだけでなく、非常に複雑な場合もあります。場合によっては、これらのテーブルを処理する独自の API メソッドをいくつか作成する必要があり、開発者は複雑さを避けるためにそれらのメソッドのみを処理します。
したがって、フィールドを追加する必要がない場合は、水平テーブルのままにしてください。ただし、多言語機能をサポートする場合は、別のテーブルが必要になる場合があります。ただし、水平テーブルを使用することをお勧めします。
私はまた、ユーザー プロファイルを含むサイトを開発しており、水平テーブルを使用しています。将来、別の言語のサポートが必要になる場合は、言語が重要なフィールドについてのみ変更します。