[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[orca-dev:00132] ptid の採番確定のタイミング変更お願い



開発関係の皆様へ
お忙しいとは思いますが表題の件について
ご検討いただけませんでしょうか。

中山裕雄@鳥取県です。

患者IDの採番が別フォームになっていた名残りと思いますが
自由採番の設定でも自動連番の設定でもID番号のフィールドで
確定操作をすると、tbl_syskanriのkanricdのレコード1009の
kanritblフィールドの最終番号が更新されますね。
そして内部ではptnumではなく、ptidというユニークなidで全て管理されています。

され、現在のこの方法ですと、新患を登録し始めて何かトラブルがあると
kanritblの採番管理番号は増えるため、tbl_ptnumのptidとptnumの整合性が
崩れます。
(内部の動きを知った上で、注意して登録していても、ずれてくるトラブルは
現在のところ予想以上に多いです。)

全くランダムに番号を振った場合と同じで一見問題が無いようにお考えに
なられるかもしれませんが、自由採番にして、なおかつ連番になるように
気を付けるとこのこの番号の動きが大変気になります。

データは色々なことに再利用するものですが、tbl_ptnumいちいちリンクしないと
正しい患者IDにならないのは将来の災いの元になります。

改善は簡単です。
患者氏名も何も入力がない時はtbl_syskanriのkanricdのレコード1009の
kanritblフィールドの最終番号は増加せず、最低限患者氏名が登録された後に
番号を増加さされば(というか書き込みのタイミングです。)問題はなくなります。
つまり、あるIDを入力して患者氏名が呼び出せる段階になってから、最終番号が
記録されれば、連続で番号を入力するかぎり、tbl_ptnumのptidとptnumの整合性は
崩れません。

さらに、もしご検討いただければ、この最大番号をsyskanriのテーブルに書き込むの
ではなく
登録患者の最大ID+1というダイナミックな情報から取得すれば、最終患者を何らか
の
理由で削除した場合(受診を途中で止めたとか、意外にあるものです。)でも、番号
が
不連続にならずに済みます。

データを自分で再利用しないユーザーにはどうでもよいことのようで、
この内部ID問題はSQLDBのデータを扱うユーザにとっては決定的に大きな意味があり
ます。
データをレコード単位にばらしても、人間が特定のIDを読むことで、データの帰属が
どこなのか、テーブル同士をリンクさせなくても、人間の目で確かめうる構造にして
あると
後になればなるほど、データが増えれば増えるほど、意味を持つようになります。

以上、長々と書きましたが、ご検討のほどよろしくお願い致します。

中山小児科内科医院
中山裕雄