3

私は、ユーザーに自分自身に関する情報と一致するユーザーの好みに関する情報を提供させることにより、出会い系サイトと同じように機能するFacebookWebアプリケーションを作成しています。

私はこのためのデータベースを作成しており、次の設計を念頭に置いています。

  • メンバーテーブル： FBIDを主キーとして使用しているユーザーに関する情報が含まれています。
  • プリファレンステーブル： ユーザーが必要とするプリファレンスに関する情報が含まれています。

ユーザーが設定を指定できるフィールドは約20ありますが、それらはすべてオプションです。「設定」テーブルを構成する最善の方法がわからないため、現在2つのアイデアがあります。

解決策1： Facebook IDの外部キーを使用し、照合できるフィールドごとに新しい列を作成します。私が見ることができる問題は、値が指定されていないフィールドのデータベースに多くの「null」値が存在することです。

  • データベースの「null」値はスペースを占有しますか、それとも他の問題を引き起こしますか？

解決策2： Facebook IDの外部キーを再度使用しますが、次の2つの列では、キーと値のペアのアプローチを使用します。したがって、一方の列にはユーザー設定のIDが含まれ、もう一方の列にはその値が含まれます。ユーザー設定ごとに、「ユーザーID」-「設定ID」-「値」という構造のレコードがあります。

  • これに関する問題は、「value」列の値のタイプが「preferenceID」列の内容に依存することです。

私の質問：

  • どちらのアプローチが良いですか？
  • この種のWebアプリケーションに対する標準のスキーマソリューションはありますか？
4

1 に答える 1

2

お気づきのように、いずれにしても妥協点を見ています。どちらの方法を取るかは、本番データが実際にどのようになるかによって異なります。

スパース テーブルの NULL 値は少しスペースを占有しますが、列が可変長データを使用している限り、それほど多くはありません。10 個の null varchar はそれほど長くありません。10 個の null int は、10 個の非 null int と同じ長さです。

2 番目のソリューションで「プリファレンス ID」をキーとする 3 番目のテーブル「PreferableThings」を追加すると、技術的には、ほとんどの人が避けているキーと値のペアまたは EAV ではなくなります。ご指摘のとおり、問題は、さまざまなデータ型の設定を共通のエンコード形式 (通常は varchar) で保存する必要があることです。これにより、スパース テーブルの問題は解決されますが、一般的なデータ型から適切なネイティブ データ型にデコードするためのアプリケーション ロジックを作成する必要があります。これを行うためのルールを「PreferableThings」テーブルに保存できます。

ただし、2 番目のアプローチのもう 1 つの利点は、新しい設定オプションの追加をテーブル駆動できることです。ソリューション 1 では、スキーマの変更が必要になります。

于 2012-07-27T11:43:19.303 に答える