「伝票テーブル」ってあるべきなのか。という話。
ちょっとお仕事で「伝票」を取り扱うことになったのだけれど。どうにもテーブル構造が決まらず。（正確にはきまってるけど）
もしやということでちょっとだけ書いてみる。
目次
ひとまず前提
まー大体。世の中依頼と受注が発生する業務には「伝票」がついて回ってくる。
依頼時の情報と受注情報。あとは受入なりするから検収なり受入なりの伝票がつく。
依頼者「これこれこういったものをお願いしますね。」
受注者「ハイ了解。これででゲスね」
依頼者「うけとったで。おけまる！完璧！」
というわけで、その取り交わしの記録として伝票が発行されて、こと細かな部分は「明細」という単位でくっついていく。
こんなもんよ。
これ自体は大きく間違っていないし側面的にはあっている気がする。
IPAの過去問でもこの類のもんはたびたび出てくるし、大体以下の様子。
gyazo.com
引用元：IPA 独立行政法人 情報処理推進機構：問題冊子・配点割合・解答例・採点講評（2020、令和2年10月）
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2020r02_oct/2020r02o_db_pm1_qs.pdf
はて、しかしこれ本当にいいのか？というのが今回の前提。
「伝票」は契約における一時的な記録のスナップショットでしかなく、永続化に値しないのでは？
ということ。
なにが問題なの
いや。いまのままでも特に問題はないんだけど。柔軟性が失われているような気がしている。
それどころか「記録」としていつでも取り出せる状態ではあるべきなんだけど。ただ伝票を取り扱うサービスとしては
コアではない。そんな感じ。あくまでもスナップショット。データから生成できればよい。
間違ってもそのままの形でつかっちゃいけないんじゃないの？ということ。
やつらはあくまで「発注依頼時」であったり「受注時」の状態。事実を記録するのはいいんだけど。
情報が増えたり、減ったり。形式が変わったことに対して非常に脆い。
じゃぁどうもつべきだろう。
やはりここは「だれが」「なにを」といった「記録」のみに着目していくべきだとおもう。
具体的にはこんなノリで。
gyazo.com
依頼に紐づくスター型というか。そもそもそこに対する記録を種別に応じて記録すべきだろうと。
結局各種「伝票」はここから用意に生成できるだろうし、よくてviewとして持つぐらいだろう。わざわざ実体を持つ必要はないはず。
この構成の強みは
・情報が増えた場合にテーブルを追加するだけで対応ができそうなところ。（できそう。）
・ＲＤＢじゃなくてもいいかもしれない。key-value型とも相性もそこまで悪くないように思う。
・ユーザーの目に触れる「伝票」の部分を「view」に落とし込むので見ための影響を受けにくい。
やったことはないのだけれども。だいたい構成はきまってるし紙もとに起こされたデータベースを眺めるぐらいしかないのだけれど。
過去のある点をとるのは若干めんどうではある。要件に応じて永続化用のテーブルがあるのはよいと思う。
なんでこんなことになってるのだろうか
おそらく元々紙だったものをそのままデータ化する形で設計をしてしまったから。
長いこと電子カルテと戦っていたけど、あっちも診療録という元々もは紙の情報をそのままデータベースに押し込んでいる。
結果的に非常に取り扱いの面倒なデータベースができあがってる。たぶん記録としての紙をそのままデータベースに落とし込むのは
多くの場合誤りだと思われる。
データベースは記録を残すものではあるが、例えば合計金額のような計算で出力可能な項目を保持するのは基本的によくない設計。
であれば「伝票」なんてものはまさしくその集合のようなもので、基本的にはデータベースに保持しないほうがいい。
いつしか紙ではないデータベースにお目にかかれるといいなぁ。その時は「紙をベースにしなきゃだめだ！！！」とか言ってるような気がするけど。
いじょう。
