2009-04-09 4 views
0

私はOOP/OODにはかなり新しく、学ぶことがたくさんあることを実感していますので、SOコミュニティに彼らの意見を聞きたいと思います。これは、電子商取引サイトのオブジェクト指向設計ですか?

CREATE TABLE `categories` (
    `id` int(11) unsigned NOT NULL auto_increment, 
    `name` varchar(255) default NULL, 
    `parent_id` int(11) default NULL REFERENCES categories(`id`), 
    `lft` int(11) default NULL, 
    `rght` int(11) default NULL, 
    PRIMARY KEY (`id`) 
); 
CREATE TABLE `products` (
    `id` int(11) unsigned NOT NULL auto_increment, 
    `name` varchar(255) default NULL, 
    `artist_id` int(11) default NULL REFERENCES artists(`id`), 
    `description` text default NULL, 
    `category_id` int(11) default NULL REFERENCES categories(`id`), 
    `status` enum('in stock', 'pre-order', 'out of stock') NOT NULL, 
    `price` decimal(6,2) default NULL, 
    `picture` varchar(255) default NULL, 
    `picture2` varchar(255) default NULL, 
    PRIMARY KEY (`id`) 
); 

オンラインストアがされています

基本的に、私は次のCREATE文で説明CakePHPのMVCフレームワーク、そして私はちょうど2つのモデル、カテゴリーや製品を使用している建物だオンラインストアを、使用しています包含することを行く:

  • 音楽
    • のCD
    • のDVD
  • アパレル
    • パーカー
    • Tシャツ
    • ベビードール
  • 帽子
  • 長袖Tシャツ
  • その他マーチ
    • ステッカー
    • ポスター
    • トートバッグ
  • ダウンロード
    • 着メロ
    • MP3ファイル

これは基本的にカテゴリツリーの構造ですが、今後新しいカテゴリを追加することもできます。現在、すべての製品はProductクラスオブジェクトと同等に扱われ、category_idは異なるタイプの製品を区別する唯一の方法です。オンラインストアはサイトの1つのセクションにすぎません。残りのサイトには、アーティストのバイオグラフィーやディスコグラフィーなどの情報が含まれています。私はモデル/テーブルも持っています:アーティストアルバムトラック

これは良いアプローチですか?または、私はCD/Tシャツ/ MP3 /のための別のサブクラスを作成する必要がありますか... Productクラスを継承していますか?私はトラック内の各音楽CDをディスコグラフィーのエントリにリンクして、トラックのリストや製品の説明のためのその他の情報を自動的に生成したいと思います。

これは良いことではない場合、どうしたらいいですか?また、どのようなメソッド/プロパティを自分のCategory/Productクラスに含めるべきですか?カテゴリツリーの葉ノードにのみ商品を表示する必要がありますか?

編集:
明らかにこのデザインは不完全です。シリルが指摘したように、製品。価格フィールドが欠落しており、売り上げの引当金はまだありません。私は実際には&がストアのそれらの側面を実装するように設計する最良の方法を実際に試してみようとしています。ほとんどの場合、私はという別のモデル(注文)を持っていますが、実際に注文を処理するということは、配送先と注文内容に基づいて異なる送料を適用しているためです。

+0

私はあなたの主要な製品タイプごとにサブクラスを作成するのが好きです。あなたは、着信音のようなものと、サブクラスの恩恵を受ける可能性のある出荷可能な製品のために、十分に違ったやり方をしています。しかし、ちょうど私の2セント。 –

答えて

1

polymorphic behaviorを使用すると、商品テーブルを保持して、異なる「商品のサブカテゴリ」を作成することができます。これは、すべてのデータを1か所(価格など)に保つ簡単な方法です。

また、テーブルの属性に同じ多態性の動作を使用し、製品固有のものを属性(名前=>値のペア)として追加することもできます。それはすべてあなたの頭の中のアイデアとデータの量に依存します。

大規模なデータベースを使用する予定がある場合、最初の解決策はおそらくより良いでしょう。

1

はい、さまざまなタイプの製品に対して、特に型固有の機能を持つサブクラスを作成する必要があります。トラックリストの自動生成と同様に、あなたは言及します。

しかし、それがなくても、別に指定された製品クラスを使用することで、製品タイプ固有のコードを扱う際に、コードをより読みやすく論理的にすることができます。

より具体的なデータベースモデルを作成することもできます。

のようなテーブル:製品
PROD_ID
...一般的なもの..

product_clothes

...服の特定のものをPROD_ID ...

product_music
PROD_ID
...音楽固有のもの...

音楽はビットレートを持っていないインチと洋服で測定された大きさを持っていないので

product_merch

...商品特有のもの。..

をPROD_ID。

+0

サブクラスがシステムをより読みやすく/論理的にするとは限りません。もちろん、これはシナリオに基づいて異なりますが、私はサブクラスのアプローチに従ったシステムと構成に基づくアプローチの2つのシステムを見たことがあります。 – eglasius

+0

私は別のモデル/テーブルを使用するのに躊躇してきた理由の1つは、そのようなデータベースを正規化する方法がわからないためです。製品がすべて異なるテーブルにある場合、どのように製品を検索しますか?それぞれのカテゴリを別々に検索し、その結果をコントローラで組み合わせますか? – Calvin

+0

@カルヴァン通知esnoejisは、検索を適用できる一般的な製品テーブルを述べました。ページに表示されているものに基づいて検索する場合は、検索エンジンとの統合を検討してください。 – eglasius

0

いいえ、

あなたは、単純なカテゴリ部門を達成することはできません(カスタムTシャツのロゴなどのような)いくつかのマンボジャンボ魔法を)必要としない限り、あなたは間違いなく別のサブクラスを作成しないでください。その場合でも、カテゴリクラス(HasLogoなど)に特別なフラグフィールドを入れるのは安全です。

しかし、デザインは私にまだ印象づけていません。どのような種類の店舗には売り込みがありませんか?値段はどうですか?

柔軟性のために、ピクチャを別のテーブルに配置することもできます。

lft/rghtは何を使用していますか?単純なIndeプロパティを使用してカテゴリの場所をツリーに格納できますが、カテゴリを削除/追加するたびに更新する必要があります。

+0

lft/rghtは、MPTT構造を実装するCakePHPのTreeビヘイビアに必要です。 – Calvin

1

category_id列をスキップして、タグクラウドのように関係をモデル化する必要があります。各製品を1つ以上のカテゴリーに関連付けることが必要になります。

artist_id列をスキップし、その関係をタグクラウドのようにモデル化する必要があります。最終的には、いくつかの製品を複数のアーティストに関連付けることになります。

カテゴリの日付は、タグクラウドを使用する必要があります。原則として、referencesステートメントでテーブルを作成する必要はありません。テーブルのすべての列にreferencesステートメントがある場合を除きます。

+0

私は、親カテゴリ以外のカテゴリに関連付けられた商品はありません。サンプラー以外にも、各製品は1人のアーティストにのみ関連付けられます。しかし、私はタグモデルの設定をしているだけで、私はどのように私はサイト全体に適用することができないのか分かりません。 – Calvin

+0

そして、なぜ私は参照ステートメントでテーブルを作成すべきではありませんか?彼らは不活性ではありませんか?私はそれらをモデルの関連付けを示すためだけに含めます。 – Calvin

+0

+1タグクラウドへのアプローチ - 私の答えでそれに関連するものを挙げました。 – eglasius

2

私は、サブクラスの代わりに構成+動作のアプローチが好きです。

これは、カテゴリレベルでの動作のビットである可能性があります。シナリオによっては、カテゴリに関係なく特定の製品に適用されるものなど、一部の動作が別の製品タイプに関連付けられる可能性があります。この最後の部分では、追加のカテゴリに関連付けられたこれらの余分な振る舞いを持つことができるので、喫煙の提案も多くの意味をなすでしょう。これにより、すでにコード化されたビヘイビアを操作している限り、サポートするビヘイビアを示す新しいカテゴリを追加できます。

小さなバリエーションは、ビットではなくカテゴリに関連付けられた動作のリストです。

追加のクラスは、プロダクトクラスの下ですべてを混合するのではなく、ビヘイビア用のクラスです。これらの余分なものにUIを関連付ける必要がある場合は、製品の種類にかかわらず、それをビヘイビアーに関連付けることができます。