web-dev-qa-db-ja.com

不動産のデータベースを設計するソリューションを探しています

不動産ウェブサイトのデータベーススキーマの一部をどのように設計すればよいか、正しい方法を探しています

「proprety_real_estat」テーブルには、国、都市、町、およびプロパティのタイプが含まれています（スクリーンショット01）

screenshot 01 スクリーンショット01

私の問題：

以下に他の多くのフィールドのホーム機能チェックリストを追加したい

Wifi（はい/いいえ）
TV（はい/いいえ）
ガス（はい/いいえ）
電気（はい/いいえ）
ガレージ（はい/いいえ）
駐車場（はい/いいえ）
バルコニー（はい/いいえ）
...
...
その他多数（スクリーンショット02）

screenshot 02スクリーンショット02

私の質問：
01-このすべてのフィールドを同じテーブル「proprety_real_estat」に追加した場合??
02-その後JSONファイルで作成した場合、このファイルのパスをフィールドに保存しますか？

他に私のものより良い解決策がある場合？

前もって感謝します

mysqldatabase-designmetadata
3
Sourceforest

何を最適化するかによります。

最小のスペース消費の最も簡単な方法は、特徴をビットとして保存するフィールドを作成することです。例えば：

Cuisine - 1
Internet - 2
TV - 4

その場合、インターネットとテレビは110 = 6になります。しかし、これは検索するのが難しくなり、機能を抽出するためにビット単位の操作を行うにはいくつかの魔法が必要です。

中盤は、 [〜＃〜] set [〜＃〜] を使用して、実際の機能を保存します不動産は別名。 yesに設定されている値。欠点は、新しい機能が必要になるたびにスキーマの変更と

SET列には、最大64の異なるメンバーを含めることができます。テーブルは、グループと見なされるENUM列とSET列の間で255以下の一意の要素リスト定義を持つことができます。この制限の詳細については、セクションC.10.5「.frmファイル構造によって課される制限」を参照してください。

（from http://dev.mysql.com/doc/refman/5.7/en/set.html ）

検索のための最も柔軟でおそらく最もパフォーマンスの高いオプションは、可能なすべての機能を格納する機能テーブルを持つことです。また、どのプロパティにどの機能があるかを格納するテーブルがあります。このアプローチの欠点はスペースです。 InnoDBを使用すると仮定すると、すべての行に13バイトのオーバーヘッド+ 2つの列（property_id、feature_id）〜6バイトがあります。だからあなたは20 bytes * number of properties * avg number of features per properties。 （最初のオプションを比較するには、number of unique features bits * number of properties）

create table feature (
    id smallint unsigned PRIMARY KEY AUTO_INCREMENT,
    name varchar(64) NOT NULL,
    UNIQUE KEY (name)
);

create table property_feature (
    property_id int unsigned NOT NULL,
    feature_id smallint unsigned NOT NULL,
    PRIMARY KEY (property_id, feature_id)
);

100000個のプロパティを想定した例に従って、理論的な計算は次のようになります。

30 bits * 100000 = 366kb 
20 bytes * 100000 * 18 = 35MB (still not something to worry about though)

注：実際にはおそらく30ビットをunsinged intに格納するため、4バイトかかることになります。したがって、ディスク上では約390kbを消費します。

2
Károly Nagy

これらの値のいずれかを検索、並べ替え、または集計する場合は、それらをテーブルに格納する必要があります。例えば：

  • エンドユーザーがインターネットを持たないプロパティを除外できる機能を作成したい
  • あなたの不動産マネージャーは、不動産の何パーセントがエアコンを持っているのか知りたがっています

これらの種類のタスクのすべてのJSONを抽出して分析することは、不必要に困難です。そのようなことをほとんど行う必要がないことがわかっている場合は、データを構造化されていない方法で格納することをお勧めします。

とはいえ、「機能クリープ」に注意してください。プロジェクトのかなり後の段階で次善のソリューションに縛られていることに気付くよりも、今すぐに完全に機能するスキーマを構築するための労力を費やす方がよい場合があります。ただし、機能するものをハッキングする必要がある場合は、それを実行します。

1
Andrew Brennan