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