2

データベースの設計をどのように扱うかについて、私はつまずいています。http://www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.phpのような例を見つけました。これはアイテムを販売するショップには非常に適していますが、売上を追跡するデータベースを構築したいと考えています。 (または取引) 2 人のユーザー間。

Ex John は x1、x2、x3、x4 のカードを Jane の (4 * y1)、y2、および $5.00 と交換します。(この例では、ジョンは x1、x2、x3、x4 という名前の 4 枚のカードを、ジェーンのカード 5 枚、y1 という名前のカード 4 枚、y2 という名前のカード 1 枚、および $5.00 と交換します。)

私はまた、ジェーンが追加のカードをジョンにカウンターオファーできるようにしたいと思います。

前もって感謝します

4

1 に答える 1

2

これは、リレーショナル DB 設計の興味深い例です。基本的に、私の推奨事項は、可能な限り正規化された構造を作成することです。つまり、基本的に、「このテーブルの行は一意の_ _を表す」という空白を埋めることができるようなテーブルを作成する必要があるということです。

特定のアプリケーションについては、次のことをお勧めします。

  • ユーザーのテーブル、ユーザーごとに 1 行
  • カードの表、各カードにつき 1 行 (世界にそのカードのインスタンスがいくつ存在するかに関係なく - 例としては、Topps による 1984 年のマイケル ジョーダンの新人カードの行があります)
  • 取引のテーブル、取引ごとに 1 行。ユーザー テーブルの ID を使用して、取引に関与する user1 と user2 の列を取引行に含める必要があります。カウンター オファーの機能が必要な場合は、カウンター オファーがこのテーブルの別の行にあることをお勧めします。このテーブルには、カウンター オファーの基になるオファーを参照する列「original_offer」があります。
  • 貿易品の表です。ここでは、取引に関係する各アイテムに対して 1 つの行があり、数量が表示されます。各行には、trades テーブルにマップされる tradeID、cards テーブルにマップされる cardID、quantity 列、および「from」列と「to」列があり、それぞれが関係する userID にマップされます。
于 2012-05-02T00:15:30.337 に答える