0

データベーステーブルの設計に関する提案が必要な状況があります。

バックグラウンド

PHP (正確には Cakephp ) でアプリケーションを開発しています。xml ファイルをアップロードすると、ファイルが解析され、データがデータベースに保存されます。これらの XML はファイルまたは URL フィードである可能性があり、これらはデータのさまざまなサプライヤーから購入されます。ソース url からさまざまな会場データを収集することを目的としています。会場は、ホテル、映画館、学校、レストランなどのようなものです。

問題

これらの会場の最初のテーブル構造は次のとおりです。テーブルは、最初に一般的な情報を格納するように設計されています。

id
Address
Postcode
Lat
Long
SourceURL
Source
Type
Phone
Email
Website

さまざまなソースから得られるデータが増えるにつれて、さまざまなタイプの会場には多くの属性があることに気付きました。

たとえば、ホテルは次のような属性を持つことができます

price_for_one_day, types_of_accommodation, Number_of_rooms etc

学校にはそれらがありませんが、属性のセットが異なります。レストランには他の属性があります。

私の最初のアイデアは、 vanue_attribute_names 、 Venue_attributes という 2 つのテーブルを作成することです。

##table venue_attribute_names
_____________________________
id
name

##table venue_attributes
________________________
id
venue_id
venue_attribute_name_id
value

そのため、新しい属性を検出した場合は、その属性とその値を関係を持つ属性テーブルに作成します。しかし、これは正しいアプローチではないと思います。これには他のアプローチがあると思いますか？また、テーブルが巨大になると、結合や SQL クエリが増加するため、パフォーマンスの問題が発生する可能性があります

列として可能なすべての属性を持つ可能な限り広いテーブルを作成するのは正しいアプローチですか? 私にお知らせください。参照できるリンクがあれば、それをたどることができます。ありがとう

4

2 に答える 2

2

これは驚くほど一般的な問題です。

説明するデザインは、一般に「エンティティ/属性/値」またはEAVとして知られています。そのデータのスキーマが何であるかを事前に知らなくても、あらゆる種類のデータを保存できるという利点があります。クエリが難しいという欠点があります。特定の場所にあるすべてのホテルを検索することを想像してみてください。1日の宿泊料金は100ドルから150ドルで、名前は「Waldorf」で始まります。すべての属性に対してクエリを記述し、ブール論理を適用することは、思ったよりもすぐに難しくなります。また、「hotel_nameはnullであってはならない」、「daily_room_rateは数値でなければならない」などのデータベースレベルの整合性チェックを簡単に適用することはできません。

これらの懸念のどちらも心配しない場合は、おそらくあなたのデザインはうまくいきます。

2番目のオプションは、「共通」フィールドを従来のリレーショナル構造に格納することですが、バリアントデータをある種のドキュメントに格納することです。たとえば、MySQLはXMLをサポートします。これにより、XMLスキーマを定義し、XPathなどを使用してクエリを実行できます。

このアプローチでは、スキーマ制約を適用できるため、EAVよりも優れたデータ整合性が得られます。これは、処理するデータのタイプごとにスキーマを作成する必要があることを意味します。それはあなたにとって大丈夫かもしれません-私はビジネスが毎週何十もの新しい会場タイプを追加しないと推測しています。

XMLクエリを使用したパフォーマンスは注意が必要な場合があり、一般的なツールと開発アプローチでは、「単なるSQL」よりも構築が難しくなります。

リレーショナルデータベースを使い続けたい場合の最後のオプションは、単に弾丸をかみ、「純粋な」SQLを使用することです。共通の属性を持つ「マスター」テーブルと、レストラン固有の属性を持つ「レストラン」テーブル、ホテル属性を持つ「ホテル」テーブルを作成できます。これは、管理可能な数の会場タイプがあり、予期せずに発生しない限り機能します。

最後に、NoSQLオプションを確認できます。

于 2013-02-19T12:48:46.817 に答える
0

リレーショナル データベースに固執している場合は、それだけです。あなたがリストしたオプションは、彼らがあなたに与えることができるものです。

あなたの状況では、 MongoDB (または他のドキュメント指向の NoSql システム) が適切なオプションになる可能性があります。このデータベース システムは、属性が異なるレコードが多数ある場合に非常に適しています。

于 2013-02-19T12:32:02.257 に答える