-1

病院管理システム用の PHP ブラウザ ベースのアプリケーションがあります。状況は、支払いが行われる3つの部門があるということです。受付、研究室、薬局。上記の各場所の労働者は異なり、彼らのインプットも異なります。これらの各部門は、領収書と呼ばれる 1 つのテーブルに領収書情報を送信するため、テーブルの最後の ID の次の ID である ID が生成されます。データは、この ID (テーブルの最後の ID に基づいて生成されたもの) に基づいて同じ部門に送り返されます。

この問題は、2 つの部門が同時に送信ボタンをクリックすると発生します。その時点で、最後の ID は両方のクエリで同じであるため、これらの人々は両方とも同じ ID を取得します。これにより、データの保存と部門への返送に問題が発生します。

これに対する解決策はありますか？トリガーが解決すると言われましたが、そこに行って単純にしたくありません。ランダム ID 生成を考えましたが、レシートに表示されるので、病院の担当者は連続 ID を望んでいます。また、システムの速度が (かなり) 低下しないことも考慮してください。

編集:おっと、ここにはもっと多くの情報があるようです。そのため、自動インクリメントは機能していません。考慮すべき3つの列があります。id(Pkey)、レシート番号、デビット番号。人が同時に支払うと、ID とレシート番号は一緒に 1 増加し、デビット番号は空になります。しかし、後で支払う場合、領収書番号は NULL になり、ID と debitno は最後に入力された ID から 1 ずつ増加します。したがって、領収書番号 (部門担当者に返送される予定) が記入される必要はなく、自動インクリメントが機能しない場合は正しいですか? あなたのソリューションesp autoincrementに再び感謝します。

4

2 に答える 2

9

AUTO_INCREMENTデータベースが一意の ID 生成を処理するように、ID 列に (MySQL) フィールドを使用します。他のデータベース システムにも同様のフィールドがあります。たとえば、serialPostgreSQL のフィールド タイプです。

于 2011-10-12T06:33:50.320 に答える
1

あなたの質問の更新を読みましたが、そのデータベースを本当に分割する必要があります。承知しましたが、一意の ID を使用して新しい注文を作成する必要があります。ただし、注文はすぐに支払われない可能性があるため、注文が支払われると、一意の領収書番号も必要になります。受信用の乱数を生成し、フィールドを一意にし、データベース内のフィールドをエラーなしで更新することができます。これはめちゃくちゃヤバい。

支払い用の新しいテーブルを作成することをお勧めします。したがって、注文テーブルには、自動インクリメントされた orderID (TheifMasters の回答による) と、ユーザー ID、顧客 ID、日付、説明などの他のデータが格納されます。その後、支払い ID (自動インクリメント) を格納する支払い/トランザクション テーブルが作成されます。 orderID (orders テーブルに関連する)、支払い日、ステータス、金額など。

これは、支払いトランザクションを追跡するための推奨される方法です。どこから始めればよいかがわかったので、実際にこれを実装する方法について調査を行う必要があります。リレーショナル データベースを使用するのには理由があります。

于 2011-10-12T10:23:59.557 に答える