追加のフィールドのデータベース、別のテーブルまたは列？

Question

私はStockテーブルを持っています。

sku 
quantity 
quantity_sold 
price 
seller 

私は在庫テーブルからstock and sellerを使用しますが、から数量を使用し、イベントチケットの

stock # references stock 
quantity 
quantity_sold 
price 
date_at 
time_at 
datetime_rule # foreign key to another table, it is a rule that describes when events occur 

（イベント・チケットと考えることができます）日付/時刻のプロパティを持っている製品のStockExtraテーブルを持っていますStockExtraテーブル。異なる日付の航空券には数量と価格が異なるためです。

テーブルを分割しましたが、ベストプラクティスであるかどうかはわかりません。

今、別のマーケットストアの在庫データを保持する別のテーブルを作成する必要があります。
（私は売り手が複数の店舗で商品を販売する際に在庫を管理できるシステムを作っています）

たとえば、amazon.comやebay.comでイベントチケットを販売することができます。 価格、各店舗の数量は異なる場合があります。

したがって、StockからStoreStockまで1対多の関係があります。

Stockは、すべての店舗のデフォルト価格と集計数量/ quantity_soldを保持します。 StoreStockは個々の店舗のデータを保持します。

同じ理由でStockExtraからStoreStockまで1対多の関係が必要です。つまり、価格/数量はイベントチケットの日付/時間ごとに異なる場合があります。

現在の設定では StockStockExtraとStoreStockとなります。

チケット以外の商品で日付/時刻に関連するフィールドが空白になっても、StockとStoreStockの方がよいでしょうか？

Answer 1

すべてを一貫性のある方法で保つことによって、システムの複雑さを軽減することを検討する必要があります。複雑なシナリオを単純なシナリオと同じテーブルに保持する。あなたのコードは、状況に応じてデータを見つけるために、分岐余分を持つようにした状況を作成している（StockExtra、またはStoreStock対Stock対例えばStock）別の場所で同じ情報を保持することにより

。

1回のトランザクションでデータを処理する場合、分岐は世界の終わりではありませんが、書き込み、デバッグ、および保守のためのコードが増えています。しかし、データの後に集計を置くと、複数の潜在的な場所にまたがってデータが取得されます。はさらに複雑になります。

すべてを最も詳細なレベルに保つことをお勧めします。したがって、特定の状況に適用できるストアが1つだけある場合でも、すべてがStoreStockになります。明らかにパフォーマンス上の問題がなければ、をStockから分割しないでください。Stockにnull値の列を使用してください。

デフォルト価格をStockにしておいても問題ありませんが、あなたのコードを維持しなければならない次の人のために、よりわかりやすい名前を使用してください。 Stockテーブルの販売数量を追跡することはお勧めしません。これはStoreStockにのみ保管してください。あらかじめ計算した数量を手元に保管しないでください。これは避けられないことではないでしょう。代わりに、追加された数量（領収書）と削除数量（売上）を追跡し、手元にある量を動的に計算します。これにより、在庫調整の問題が回避されます。