2

次の目的で単純な在庫システムを作成したいと考えています。

  • 在庫を記録する
  • 製品の在庫がなくなったときにユーザーに警告する
  • 販売と購入を追跡する
  • 製品の有効期限が近づいたときにユーザーに警告する (おそらく 7 日前)
  • ユーザー アカウントを作成するには、admin を使用します (すべてのユーザーはログインする必要があります)。

必要なテーブルの数と、何を含めるべきか、よくわかりません。私は次のことを試しましたが、うまくいかないようです：

Sales(Serial_Number,Name,Unit,Quantity,Amount,Sale_Date) Purchases(Serial_Number,Name,Unit,Quantity,Amount,Purchase_Date,Expiry_Date) Users(Work_Id,First_Name,Last_Name,Username,Password,Confirm_Password)

Visual Studio 2010 と MySQL を使用しています

4

2 に答える 2

4

私は最近在庫システムを作成しましたが、いくつかのフィールドが非常に役立つことが証明されています。すべての行と「IsActive」ビットに「作成された」日時を含めるようにしました。これは、何かを削除することを選択したときにfalseに設定されます（したがって、すべての削除はソフト削除です）。私のデータを説明するための、うまく、しかし過度ではない正規化されたスキーマ。

単純なインベントリが必要で、2 つまたは 3 つのテーブルでカバーできると考えている場合は、おそらく 20 ～ 30、またはそれ以上になる可能性があります。たとえば、items を 1 つのテーブル、itemtypes を別のテーブル、itemcategories を別のテーブルにします。アイテム、購入、販売などの個別の履歴テーブルを必ず用意してください。

最も広いカテゴリから始めます。たとえば、在庫など、説明する必要がある可能性のあるすべてのテーブルでそれらを具体化します。箱、釘、ハンマーがある場合は、「コンテナ」、「ハードウェア」、「ツール」をリストするカテゴリ テーブルが必要になる場合があります。

インベントリに追加するハンマーごとに、アイテム テーブルの新しい行で、アイテム タイプ「ハンマー」を参照する必要があります。その後、それぞれが販売されると、各アイテムのステータスを変更できます。持っているハンマーの数を知りたい場合は、ステータスが利用可能な「ハンマー」タイプのすべてのアイテムについて、アイテム テーブルをクエリします。ハンマーが売却された場合、売却済みに変更します。ハンマーが良好な状態で返却された場合、その特定のアイテムを [利用可能] に戻します。

行を削除しないでください。「IsActive」ビットを false に設定するだけです。そうすれば、データが「削除された」アイテムにリンクしている場合でも、後でデータに関するレポートが正しく機能し、一般的な使用中に IsActive = 1 のアイテムをクエリすることができます。

他にもたくさんあると思いますが、これが私のテクニックです。コメントを歓迎します。学ぶことは常に良いことです。

于 2012-10-31T08:39:57.480 に答える
3

  • 在庫を記録する

    現在のデータ構造では、これは非常に簡単ではありません。履歴全体を調べて、すべての販売を完了するためにどの購入が使用されたかを検討する必要があります (そして、決定が実際に正しいと仮定します)。利用可能な在庫の追加のテーブルを維持する方がはるかに簡単です。

    available_stock ( Serial_Number, Quantity, Expiry_Date )

    その後、MySQL のイベント スケジューラを使用して、期限切れの在庫を自動的に削除できます。

    CREATE EVENT remove_expired_stock
ON SCHEDULE EVERY DAY STARTS CURRENT_DATE
DO DELETE FROM available_stock WHERE Expiry_Date < CURRENT_DATE

    データベース操作をトランザクションでラップして原子性を確保できるように、各テーブルで InnoDB ストレージ エンジンを必ず使用してください。

    START TRANSACTION;

SELECT SUM(Quantity) FROM available_stock WHERE Serial_Number = ? FOR UPDATE;

-- only proceed if quantity is sufficient for a sale

SET @q := ?;  -- quantity required

UPDATE   available_stock
SET      Quantity = GREATEST(@d, 0)
WHERE    Serial_Number = ?
     AND (@d := Quantity - @q) IS NOT NULL
     AND (@q := -LEAST(@d, 0)) IS NOT NULL
ORDER BY Expiry_Date;

DELETE FROM available_stock WHERE Quantity = 0;

INSERT INTO Sales ...

COMMIT;

    テーブルにトリガーを定義して、新しい在庫をテーブルに自動的Purchasesに挿入することもできます。available_stock

    CREATE TRIGGER new_stock AFTER INSERT ON Purchases FOR EACH ROW
  INSERT INTO available_stock
    ( Serial_Number, Quantity, Expiry_Date )
  VALUES
    ( NEW.Serial_Number, NEW.Quantity, NEW.Expiry_Date );

  • 製品の在庫がなくなったときにユーザーに警告する

    「アラート」が何を意味するのかは完全には明確ではありませんが、アプリケーション コードから定期的に何らかのチェックを実行し、必要に応じて通知を送信することをお勧めします (電子メール、SMS など)。

  • 販売と購入を追跡する

    既存の構造により、それが可能になります。

  • 製品の有効期限が近づいたときにユーザーに警告する (おそらく 7 日前)

    上記のように。

  • ユーザー アカウントを作成するには、admin を使用します (すべてのユーザーはログインする必要があります)。

    これはアプリケーション内で強制されますが、これまで行ったようにユーザーをデータベースに保存することもできます。独自の認証システムを展開する際には、多くの一般的な落とし穴があることに注意してください。すべてがプロジェクトに直接関係するわけではありませんが、フォーム ベースの Web サイト認証の決定版ガイドは優れたリソースです。

  • テーブルの数と、何を含める必要があるのか​​ よくわかりません。

    これの多くは、独自のプロジェクトの要件に依存します。おそらく、どのレベルの情報を記録し、どのように使用するかについて、腰を据えて考える必要があるでしょうか。

    ただし、いくつかの観察事項があります。

    1. 各テーブルに「名前」と「単位」を含めるのではなく、その情報を含むSerial_Number別のテーブルに外部キーを作成Productsします。

    2. Password表にとConfirm_Passwordの両方を含めないでUsersください。パスワードがすでに確認されている場合にのみ、パスワードを記録する必要があります (その場合、プレーンテキストのパスワード自体ではなく、ソルト化されたハッシュのみを記録する必要があります。上記のリンクにある認証のガイドを参照してください)。 .

  • 私は次のことを試しましたが、うまくいかないようです：

    @Olaf Dietsche がコメントしたように、「機能していないように見えるもの」を説明すると、一般的に役に立ちます。現状では、10,000 行のコードを記述して 1 つの小さな部分に苦労しているのか、それとも「これらのテーブルを作成しただけで、在庫管理システム全体が魔法のように現れることを期待しています!

于 2012-10-31T09:24:31.470 に答える