0

次のテーブルがあります。

品目 { item_id, item_name, item_price,......}
部門 { 部門 ID, 部門名, 部門住所,.......}
倉庫 { 倉庫 ID, 倉庫名,........}
倉庫区画 { パーティション ID, partition_name,........}
WarehouseRacks {rack_id, rack_name,.......}

さて、アイテムの場所を追跡するために、次のテーブル (リレーション) があります。

itemLocation {item_id、division_id、warehouse_id、partition_id、rack_id、floor_number}

アイテムの場所を正確に追跡しますが、アイテムの場所情報を取得するには、パフォーマンスの問題を引き起こす可能性のある 5 つのテーブルを結合する必要があります。

また、フィールド全体を取得しない場合、テーブルには主キーがありません。これにより問題が発生しますか? これを達成するためのより良い方法はありますか?

ありがとう。

4

2 に答える 2

1

Gilbert Le Blanc が書いているように、おそらく 5 つのテーブルに参加する必要はなく、「WarehouseRacks」に参加するだけでよい場合があります。

ただし、「追跡する」必要があると書いています。これは、時間の側面が関係していることを示唆しています。

これにより、次のスキーマが得られます。

Items { item_id, item_name, item_price,......}
Divisions { division_id, division_name, division_address,.......}
Warehouses { warehouse_id, division_id, warehouse_name,........}
WarehousePartitions { partition_id, warehouse_id partition_name,........}
WarehouseRacks { rack_id, partition_id, rack_name,.......} 
ItemLocation (rack_id, item_id, entry_time, quantity, floor_number)

ItemLocation では、3 つの列すべてが複合主キーの一部です。つまり、「一度に特定の場所にある項目のインスタンスは 1 つしか存在できない」ということです。

アイテム ID を取得するには、5 つのテーブルに結合する必要があります (少なくとも住所や名前などが必要な場合)。最新のハードウェアとデータベース ソフトウェアを使用している場合、これで問題ありません。膨大な量のデータを扱っていない限り、外部キーと主キーの関係での 5 方向の結合によってパフォーマンスの問題が発生することはほとんどありません。コメントで言及した量と、これを MySQL で実行するという事実を考えると、結合の数について心配する必要はないと思います。

このモデルの利点は、品目ロケーション テーブルに無効なデータを挿入できないことです。品目がパーティションに存在しないラックや、パーティションに存在しない倉庫にあるとは言えません。分割; 倉庫の区画が変更された場合、すべての item_location レコードを更新する必要はありません。

SQLFiddleを作成して、それがどのように機能するかを示しました。

「item_location」テーブルは、これにおける最大の懸念事項です。スナップショット (この設計が行うこと) を保存するか、トランザクション テーブルを保存するかを選択する必要があります。「スナップショット」ビューを使用すると、コードは常に「数量」列を更新し、「entry_time の時点で、このラックのこのフロアには x 個のアイテムがあります」と事実上伝えます。

「トランザクション」モデルでは、複数のレコードを挿入できます。通常、アイテムを追加するときは正の数量、アイテムを削除するときは負の数量です。任意の時点でその場所にあるアイテムは、目的の時間までのこれらの数量の合計です。

于 2013-02-14T15:29:46.353 に答える