1

Apache サーバー上で PHP を使用して Web アプリを構築しています。

このアプリには、人に関する多くのオプション データが含まれています。個人のカテゴリに応じて (1 人の人物が複数のカテゴリに属する​​可能性があります)、データを指定するかどうかを選択できます: 自宅の住所 (== 通り、都市、国などの 5 つのフィールド)、勤務先の住所 (ここでも 5 フィールド)、年齢、電話番号、....もちろん、アプリはいくつかの追加データも保存します (作成、最終更新、ユーザー名、パスワード、ユーザーレベルなど)。

アプリの現在/古いバージョンには、「users」テーブルに 86 のフィールドがあり、(人のカテゴリに応じて) 別の 23 のフィールド (1-1 関係) を持つ追加のテーブルで拡張されています。

これらはすべて Postgresql データベースに保存されます。

これがこのタイプのデータを処理する最良の方法であるかどうか疑問に思っています。ほとんどのレコードには（多くの）空のフィールドがあり、データベースが大きくなり、クエリが遅くなります。Triple Store のような他のソリューションを検討する価値はありますか、それとも心配しすぎて現在のセットアップを維持する必要がありますか? サイトの新しい目的ごとにテーブルにフィールドを追加するだけというのは、奇妙に思え、気まずい気がします。一方で、トリプルストアはまだあまり一般的ではない印象です。これにアプローチするための指針や提案はありますか?

Toby Segaran などによる「セマンティック Web のプログラミング」を読んだことがありますが、その本から、トリプル ストアと RDF の主な利点は Web を介した情報交換にあるという印象を受けました (これは私のアプリの目標ではありません)。 )

4

1 に答える 1

0

ほとんどのレコードには (多くの) 空のフィールドがあります

これは、データが正規化されていないことを意味します。

アプリの現在/古いバージョンには、「users」テーブルに 86 のフィールドがあり、(人のカテゴリに応じて) 別の 23 のフィールド (1-1 関係) を持つ追加のテーブルで拡張されています。

確かに、そうです、それは正常化から非常に長い道のりです.

現在の場所から移動する正当な理由がある場合、最初のステップはデータをより適切に構造化することです。noSQL や object db など、別のタイプの DBMS に移行することを選択した場合でも。

これは DBMS のスペースを節約するだけでなく、データの取得を高速化し、記述する必要のあるコードの量を削減します (たとえば、自宅の住所を維持するための同じコードを職場の住所を維持するために再利用できます)。アドレスのタイプにフラグを立てるフィールドを持つ「アドレス」の単一テーブル)。

Web 上には (上記のウィキペディアのリンクに加えて) 正規化のルールを適用する方法を説明しているリソースがたくさんあります (1、2、3 の後で少し複雑になりますが、これらをマスターできれば問題ありません)ほとんどのタスクを引き受けるために装備されています)。

于 2011-09-07T12:34:21.013 に答える