0

eコマースドメインのモデリングについてアドバイスが必要です。

クライアントは2つの製品を販売しています。

  1. カスタムアートワーク、お客様が指定したデザイン。
  2. お客様が指定した裏面にメッセージが書かれたアートプリント。

これが私のこれまでのデータベースモデルの縮小です。

Products:
    Id
    Description
    Price

Orderlines:
    Id
    OrderId
    ProductId

Attributes:
    Id
    Name

OrderAttributes:
    AttributeId
    OrderlineId
    Value

商品表には、上から2つの商品が含まれます。

注文明細は、選択した製品を注文にリンクします。

属性は、各製品のカスタムフィールド名を保持します。

たとえば、カスタムアートワーク製品には属性デザインがあります。

注文属性は、注文された製品をその税関属性にリンクし、値を持ちます。たとえば、家をペイントする価値のある、デザインの属性を持つカスタムアートワーク製品。

また、nhibernateを使用して、このデータベースモデルをコードにマッピングしたいと思います。

このデータをモデル化するより良い方法はありますか？

4

2 に答える 2

2

いくつかの提案：

Orderlinesテーブルには、既存の注文に影響を与えることなくアイテムの価格を変更できるように、製品の価格（および場合によっては説明）が含まれている必要があります。同様に、注文テーブル（表示されていません）には、変更される可能性のある顧客情報（配送先住所など）が含まれている必要があります。注文を構成するデータは変更できません。最も簡単な方法は、注文をフラット化して非正規化することです。

OrderAttributes構造は、エンティティ属性値モデルと呼ばれ、多くの欠点があります。一般的には、それを避け、必要な列をOrderlinesテーブルに追加することをお勧めします。必要に応じて、アプリケーションでProductとOrderLineをサブクラス化して、CustomArtWorkProductが注文に追加されたときにCustomArtWorkOrderLineを作成できるようにすることができます。

于 2013-01-16T15:02:10.203 に答える
0

オブジェクト指向プログラムでは、関係は関連として表されます。

あれは：

  • 製品に注文がある場合、製品には注文のコレクションが必要です。
  • 注文が製品に対するものである場合、注文にはプロパティProductが必要です。
  • 等々。

オブジェクト指向プログラミングでは、識別子で関連付ける必要はありません。これは階層データによって支配される別の世界であるため、これは必要ありません。

正直なところ、私が前に言ったことに従えば、NHibernateは、ユーザーの介入なしにオブジェクトとプロパティをロードできるため、非常に強力なツールになります。

「ある製品のすべての注文を取得する」ことを考えてください。意図的にSQL結合を実行するのではなく、のOrdersプロパティにアクセスし、 ProductNHibernateがこのアクセスをデータベースの世界に変換します。

これがOR/Mを使用するポイントです。「テーブルをそのままマップする」だけではありません。それは、2つの非常に異なる世界を結合することです。オブジェクト指向の階層的な世界と、苦痛のないリレーショナルデータです。

この非常に古い（2004年！）CodeProjectの記事と、NorthwindSQLServerデータベースベースのモデルを作成する方法を確認してください。

モデルをデータベースにマップする方法ではなく、モデルの設計にマップする方法に注意を払う必要はありません。

この記事をチェックしてください、それは他のものより現代的です：

于 2013-01-16T09:22:22.467 に答える