0

注文を追跡するための注文システムを作成しています。約60の製品があり、それぞれに独自の価格があります。システムはそれほど複雑ではありませんが、注文した各製品の数を送信できる必要があります。

私の質問は、各製品を表す列と、注文した各製品の数を表す数値を含む「注文」テーブルを作成する方が効率的かどうかです。例：

orders
    id
    product_a
    product_b
    product_c
    etc...

また

それを別のテーブルに分割し、それらを結合するために多対多のテーブルを使用する必要があります。多分このようなもの：

customers
     id
     name
     email

orders
     id
     customer_id

products
     id
     product

orders_products
     order_id
     product_id
4

4 に答える 4

1

2番目のサンプルで示すように、私はそれを分解します。これにより、アプリケーションがはるかにスケーラブルになり、それでも非常に効率的になります。

于 2012-05-08T19:06:31.620 に答える
0

私も2番目の方法を使用します。あなたが言うようにデータベースが単純な場合、速度などの点でそれほど違いはないかもしれません。ただし、2番目の方法は、新しいアイデアを取得してアプリケーションに追加する場合に備えて、より効率的で簡単に再利用/拡張できます。

于 2012-05-08T19:08:12.787 に答える
0

最初のケースに進む必要がありますが、各製品について顧客に提供した価格と割引をどのように追跡しますか？また、現在追跡する予定がない場合でも、これは非常に一般的なことであるため、そのような変更を要求する可能性があります。

正規化されたスキーマを使用すると、いくつかのフィールドを追加するだけで済みます。

于 2012-05-08T19:18:16.510 に答える
0

常に将来の機能と拡張を念頭に置いて構築してください。ここまたはそこにあるショートカットは、後で全体を再構築してリファクタリングする必要があるときに、常にあなたを噛むようです。正規化と、リレーショナルDB内のすべての独立した要素を分離する理由を調べてください。

「この方法の方が簡単なのに、なぜ別のテーブルにするのか」とよく聞かれます。次に、「ああ、私たちが使用するこのタイプのものは他にありません」と彼らに思い出させ、後で彼らに多対多を必要とする機能を求めさせ、将来の機能を考慮せずにあなたを隅に追いやったことに気づかなかった。データ構造を理解していない人は、これを理解できない傾向があり、システム要件を指定するのがかなり苦手です。これは通常、DBが大きくなり始め、データのサブセットのみを表示できるようにしたいことに気付いたときに発生します。フラットDBとは、さまざまな要望を処理するために列を追加することを意味しますが、多対多の結合テーブルは、数行のコードでそれを実行できます。

于 2012-05-08T20:03:23.323 に答える