在庫データベースの設計

Question

私は在庫データベースのいくつかの例を見つけました。しかし、私はちょっと違うものを探しています。私はSQLを使って作業しています。

ツールを追跡する必要があります。従業員はツールをチェックアウトすることができ、そのツールの在庫は削減され、そのトランザクションは（checked_out）テーブルに記録されます。遠くまで簡単に。

従業員がツールを返すと、その従業員は選択肢を持ちます。彼はツールを在庫に戻すか、まだかなり簡単です。または、ツールを壊して捨てることができます。言い換えれば、ツールをごみ箱に記録することができます。あるいは、彼はツールをレジシャンビンに入れ、それを再研磨テーブルに記録することができました。これは私が混乱するところです。

Answer 1

インベントリテーブルにステータスが必要なようです。たとえば、任意のツールのレコードは、「ステータス」テーブルの外部キーであるステータスフィールドを持つことができます。あなたは在庫を計算する際に、場合にのみレコードを表示、次に

id  status_id  description 
------------------------------------- 
1  2   Hammer 
2  1   Hammer 
3  3   Hammer 
4  1   Saw 
5  3   Saw 

：あなたの在庫表は次のようになります

など...

ID  Description 
----------------------- 
1  Available 
2  In Use 
3  Broken 

：ステータス表には、このようになります。ツールは「使用可能」に「1」のステータスを持っています。また、管理用のクエリを実行して、「壊れた」ツールの数を表示することもできます。破損したツールが適切に処理されたら、最終的にこれらのレコードを削除するか、過去のデータ目的のためにそれらのレコードを保持します。

すべてのコストは、データベース内のエンティティの処理に別のテーブルを作成しないようにしてください。 「フラグ」フィールド（status_id）を使用すると、新しいテーブルを無限に追加する必要なく、アプリケーションに新しいステータスを追加できます。お使いの設定が間違っている

Answer 2

は、あなたがゴミ、チェックアウト、およびresharpenビンのための別のテーブルを持つべきではありません。これらは単にツールが見つかることができる状態です。何をしたい

はhis solutionにハードコーディングによって提案されたデータを収容するこれらの2つのテーブルを含むデータベースです。

Inventory 
----- 
id (PK) 
description 
status_id (FK -> Statuses) 

Statuses 
---------- 
id (PK) 

Answer 3

私はハードコードのスキーマを好きですが、それは、モデル化されている状況に近い試合になるかもしれませんステータスの代わりに場所を保存することができます（いずれにしても、私は "状態"という言葉の使用を禁じます）。場所は実際にここで追跡されているものであり、チェックアウト時にアイテムの現在の所有者を示すために使用することもできます。私は、それが全く追跡されなければならないならば、体調は別々に保持すべきだと思います。これは、ツールのユーザーフィードバックやスタッフの観察に基づいて、より細かいグレードの状態を可能にします。

（2コメントへの対応）

私はあなたが（人Zによって特定の時間に位置Bに位置Aから）ツールの個々の動きを記録するテーブルを持っているだろうと期待して別のより高いレベルの要約または現在の位置を記録する。ツールがシリアル番号で個別に識別されたかどうかは、ツールを個々に追跡するかどうか、またはそれらが個別に識別されない同じツールの数の1つであるかどうかによって異なります。これは、5つのトランザクション（各ツールに1つ）を記録するのか、5つのツールを1つ記録するのかを決定します。「5つのツールがチェックアウトされた」とまとめたり、「これらの個々のツールが現在これらの場所にある」と記述することもできます。