Coffee Break Log

業務システムを構築するにあたり、データベースとして、おおむね：

• 今季の最新台帳系（Resources, Master）
• 今季の最新伝票系（Events, Activity)
• 運用設定系、会計期とかマスタ取り込みの設定とか（Operating）
• システム系、画面パーツ配置などのパラメータとか（system)
• 分析、報告書系(Cubes, Reports)
• 今季の台帳更新履歴系（Histories)
• 今季の伝票履歴系（Journals)
• 旧データ保持(Archives)

伝票履歴系は、最新伝票系に保持し続けるとパフォーマンスやデータ領域サイズの問題が出る場合があるため、定期的に、運用モデルに応じて１カ月とか１週間とか１日で最新系から履歴系に移す、という感じです。
規模が小さければ不要かもしれません。（ずっとEventsに保持する）
なのでちょっと話は逸れるけれど伝票履歴系は別サーバという感じ。
CubeやReportsも性能の観点から別サーバですね。

台帳履歴系は、どんな意図で所持しているのでしょうか。
どんな業務でどのように使われるのでしょうか。

• データ分析の際に過去データとマッチさせるときに必要？
• 保持が法的に定められている？
• 商品マスタなどだと単価等があるから、そのタイミングでの資産額等の算出をするために遷移を保持し続ける必要がある？
• どのタイミングで履歴を取る？
  • マスタメンテやロンダリング(改廃)のタイミング？
  • 期首/期末？（これはArchives移行、とするべきな気がするが） 　　
  • マスタメンテって、たとえばPOSでの売価変更の際は履歴取られる？(変更伝票じゃなくて台帳の過去データとして？) 　　
  • リアルで売上を転送しているとき、在庫数は減るとおもうけどれはどんどん履歴取られる？ 　　
  • あるいは、締め時刻でバッチが流れたときに履歴が取られる？
• その他なにか思うところ

自炊。豚バラ薄切りをゆでて覚まして豚シャブサラダ。
いい感じ。
http://tweetphoto.com/35897667

検査が終わると「次は○○に行ってください」といわれるんですが、その指示が完全に「眼で眺めて混んでないと思われるところ」。
この指示の精度が低いのも、待ち時間が長くなる要因だと思います。
ここはもうちょっとシステム化とかできないものか。 一人が検査にかかる大体の時間は統計とれているだろうから、カルテ（というか検診票？）をはさむバインダにRFIDを埋め込んで、トレイに乗っている検診票のバインダ数を読み取り、待ちキュー数と処理時間で推定待ち時間を割り出す。
指示する係員にはモバイル端末もたせてリアルタイムで正確な待ち時間を表示する。
壁に何箇所か、いまから来た人の待ち時間を表示する大画面デバイスを掛けるのもいいかもしれない。
電磁波による医療機器への影響などあるので、ハードウェアとしての安全基準的にはシビアな技術が必要だとは思うけれど、ソフトウェア的には簡単なシステムとして構築できると思います。
(というか、きっとそんなシステムパッケージは世にたくさんあると思います)

あと、与太話。
健康診断では、番号で呼ばれるんですが、番号じゃなくて厨二的なニックネームで呼ばれるのはどうだろう。ネタとして。
「【いと高き天空の支配者】さん、眼底検査ですので赤い扉からはいってくださーい」
とか。うわーはずかしい。でもみんなそんなふうに呼ぶならありかも…いや、ないか。

自炊。鶏モモのグリル・タルタルソースがけ。
暑い日は酸味があるものが旨い気がする。しかし台所で火を使うとものすごく暑い。

ボタンの掛け違えって感覚でしょうかねこれ。
今回は笑い話ですむと思いますが、あるとき突然大きな断絶となって両者の関係に致命的な打撃を与える可能性があるようなコンテキストでの掛け違えは怖い。
ドメインの定義は念入りに。

自炊。めんつゆ使い切った。ギンダラの煮付け。やや生姜が足りなかった。

自炊。カレー。出張で店屋物のあと、自分ちの米食って安心する。旨い。

拙サイトのコンテンツで「いいプログラムを書こう」というのがあるんですが、「妥当なプログラムを書こう」にすべきだろうか。
でも「いい」と「妥当」じゃキャッチーさが違いますな。
「体にいい食品」「体に妥当な食品」だめだ。いいをとるな絶対。
感想とかならいいんですが、論述で「いい」を使いたい場合は、きちんと観点を明らかにしないと誤解をまねくこともありそうですね。