2009-06-01 6 views
2

プロパティに関連する多くのタイプのプロパティと多くの機能を持つ不動産Webサイトのデータベース構造を作成する必要があります。この場合に使用するmysqlテーブル構造

主なカテゴリは次のようになります。 1.ハウス(サブタイプのマンション、住宅、ロフト) 2.コマーシャル(サブタイプ:ホテル、ビル、オフィス、工場) 3.地形(サブタイプ:都市、アグリコラ、工業用、

上記のすべての項目には、ライト、ガス、部屋数、バスルーム、階数、バルコニーなどの多くの機能が定義されていますが、この機能は1つのプロパティタイプとは異なります別のプロパティを持つことができますように私は、アドレスや価格などの基本的な情報を含むpropertyという名前のマスターテーブルを持っており、3つのサブテーブルproperty_houseproperty_commercialなどの多くの分野でproperty_terrain瞬間

この構造は大丈夫ですか?私はすべてのプロパティタイプの作成と変更を3つのステップで1つのフォームにする必要があり、プロパティタイプごとに異なることになります。 propertyのような1つのマスターテーブルと、2番目のproperty_featuresのproperty_id、feature_name、およびfeature_valueを格納する場所があれば簡単でしょうか?パフォーマンスとメンテナンスに最適なのは何ですか?あなたは何を投票しますか?

ありがとうございました! :)

答えて

0

まあ、これら3つの主要なカテゴリは石で設定されていますか?将来4番目に切り詰める可能性はありますか?私はおそらくこのようなものに行くでしょう:

CREATE TABLE property (
    id int not null auto_increment, 
    name varchar(250) not null, 
    property_type int not null, 
    property_subtype int not null, 
    primary key(id) 
); 
CREATE TABLE property_type (
    id int not null auto_increment, 
    name varchar(250) not null, 
    primary key(id) 
); 
CREATE TABLE property_subtype (
    id int not null auto_increment, 
    type int not null, 
    name varchar(250) not null, 
    primary key(id) 
); 
CREATE TABLE property_feature (
    id int not null auto_increment, 
    property int not null, 
    feature int not null, 
    value varchar(250) not null, 
    primary key(id) 
); 
CREATE TABLE property_feature (
    id int not null auto_increment, 
    feature int not null, 
    value varchar(250) not null, 
    primary key(id) 
); 

私はこれが長期的には最も効果的で、時間があれば最も柔軟になると思います。この構造により

、あなたは、このようなデータを追加することができます。

mysql> INSERT INTO property_type (name) VALUES ('House'),('Commercial'),('Terrains'); 
Query OK, 3 rows affected (0.00 sec) 
Records: 3 Duplicates: 0 Warnings: 0 

mysql> INSERT INTO property_subtype (type, name) VALUES (1, 'Apartment'),(1, 'House'), (1,'Loft'); 
Query OK, 3 rows affected (0.00 sec) 
Records: 3 Duplicates: 0 Warnings: 0 

mysql> INSERT INTO subtype_feature (subtype, name) VALUES (1, 'Light'),(1, 'Floor #'); 
Query OK, 2 rows affected (0.00 sec) 
Records: 2 Duplicates: 0 Warnings: 0 

mysql> INSERT INTO property (name, property_type, property_subtype) VALUES ('Som 
e Apartment', 1, 1); 
Query OK, 1 row affected (0.01 sec) 

mysql> INSERT INTO property_feature (feature, value) VALUES (1, 'Yes'),(2, '5th'); 
Query OK, 2 rows affected (0.00 sec) 
Records: 2 Duplicates: 0 Warnings: 0 

mysql> INSERT INTO property_feature (property, feature, value) VALUES (1, 1, 'Yes'),(1, 2, '5th'); 
Query OK, 2 rows affected (0.00 sec) 
Records: 2 Duplicates: 0 Warnings: 0 

あなたはその後、かなり簡単に特定のプロパティのすべての機能を得ることができます。

mysql> SELECT s.name, f.value FROM property_feature f INNER JOIN subtype_feature 
s ON f.feature = s.id WHERE f.property = 1; 
+---------+-------+ 
| name | value | 
+---------+-------+ 
| Light | Yes | 
| Floor # | 5th | 
+---------+-------+ 
2 rows in set (0.00 sec) 
2

私は両方の経験を持っていますあなたが言及した方法。 (私はiRealty http://www.irealtysoft.com/ ver3とver4の共同開発者ですが、2つの異なる保存方法があります)。両方の方法を扱って数年後、私はすべてのプロパティの単一のテーブルを作成することをお勧めします。このパターンをSingle Table Inheritance(http://martinfowler.com/eaaCatalog/singleTableInheritance.html、Martin Fowler)といいます。程度のディスク容量aを浪費している彼らの列で持って

  1. フィールド名は、レコードの多くはでNULLを持つことになります
  2. すべてのプロパティタイプ内で一意である必要があります。

    私はこの方法の唯一の2つの欠点を参照してください小さなビット

このデータベース構造と同時に、すべてのCRUDルーチンは非常に簡単で簡単です。クエリ/ ORMレイヤを構築するのに多くの時間を節約できます。この構造を使用すると、索引を作成し、WHERE句で算術関数やその他のデータベース関数を自由に使用し、高価なJOINを回避できます。

ディスク容量が安く、開発時間がかかります。

| property_id | feature_name | feature_value |フィールドとプロパティタイプを変更するときに同じデータベース構造を維持することができます。これは、複雑なアップグレード/更新ルーチンがある場合に適しています。単一の(本番)インスタンスアプリケーションを構築する場合、アップグレードは問題ではありません。しかし、この方法ではCRUDモデルが複雑になり、したがって高価でバグが発生しやすくなります。 (その他のコード---バグの詳細)

関連する問題