いまや、事務アプリにRDBは必須になってます。生産状態管理アプリでもデータ保持にRDBが使われています。
XMLが取って代わるかのように言われた時期もありますが、XML_Fileの更新は煩雑感があり見かけません。
RDBが万全だから使われているのではなく、他に代替がないから、使わざるを得ない面もあります。
過去に頂いたコメントに「RDBは時間軸がなく一面性しかない」というのがありました。
それは、しばしば感じます。
例: 得意先マスター
Code 氏名 住所
(1) A001 鴻池艶子 東京府東京市蒲田1-1 ; 昭和10年当時
(2) A001 住友艶子 東京府東京市蒲田3-4 ; 昭和15年:婚姻による改姓
(3) A001 住友艶子 東京都大田区蒲田3-4 ; 昭和18年特別区制度による表示変更
有る特定の人のデータですが、婚姻や地域制度の変更により、氏名・住所欄が変わります。システム上のCODEはA001であり、取引上は同一顧客に変わりません。
単純な顧客マスター引用だと (1)=>(2) に変更した時点で、(1)は抹消されます。 (2)=>(3) の時点で(2)は抹消され(3)が残ります。
昭和10年から 今まで毎年、この人の取引データが残っていたとします。
昭和16年の取引状況を再発行したととき、顧客住所は、(3)で表示されることになります。
少し気の利いたマスターなら
Code 氏名 住所 有効期間(From) 有効期間(To)
の項目を保持していて、
(1),(2),(3)のデータを保持していて、再発行当時の住所で印刷することを可能にしているのもあります。
しかし、構造的矛盾として、 (2)の時の請求書発送漏れがあり、(3)の住所に再発行したいケースには対応出来ません。
これは、運用ルールの問題かも知れませんが。
個々のアプリで対応することになります。
RDBに時間軸が無いと感じる所です。
業務の仕組みを処理するのが情報処理ですが、今や処理はプログラム言語で解決する時代ではなく、RDBやF/Wに委譲する部分も多くあります。
データテーブルなどのスキーマや制約で処理している部分も増加しています。
特定のキーのデータに有効期間が必要な場合は、少なくありません。しかし、RDBの機能としてはありません。
〒番号表も現在有効な住所に対して更新がなされるので、市区町村合併で消滅した地域名には無力です。
私は、項目単位の変更履歴を取る仕組みを実装しています。
多重化やOLAP機能などの機能強化は喜ばしいのですが、業務的に現場で必須的に作られる仕組み(変更ログや更新履歴、更新日、更新者等)は標準機能で保持してもいいのでは?
と思うのです。
(P.S) 更新日、更新者は個別アプリ的性格が強いので無理っぽいですが、変更履歴や有効期間型はF/W化可能な気がします。