# DB提案メモ

組み込み機器での検討事項

"なんらかのデータベース"への期待

• へたに自作するより導入品のほうが検索ロジックが高速かも
• 抽象データ構造の定義を優先する開発スタイルが理想でしょ
• 発注元企業：抽象的データ構造を一元管理してほしい
• 請負企業：具体的データアクセスをちゃんとレイヤ化するくせをつけないとね
• 実現方法はいろいろあって、たとえばエクセルのシートからstructを自動生成するツール、とかでもOK
• (ごにょごにょ...)→(ごにょごにょ...)への流用とかで、別ホストの proc.call と自ホストのproc.call についてソースレベルで互換性を持たせたい
• アプリを作るとき、データアクセスに対して「意識的」に作ってほしい
• 繰り返しアクセス透過性を意識してつくりを考えるようにして欲しい
• (戻りメッセージのロストなどで、呼び側にリトライされても大丈夫なように設計する、あるいはその必要性を検討する)
• そのデータのWriter何人？Reader何人？を意識して処理のつくりを考えるようにしてほしい
• 人員の流動性に耐えるように。
• プロの仕事は「作ったひと≠直すひと」が多い。
• ソースの自動生成ツールなどを積極的に作っておけば、次はもっとチャレンジングな仕事をできる。
• 「重要なデータ」についての書き込みを、全部フックする仕組みを仕掛けたい
• (装置複数化に容易に対応するため)
• 顧客により二重化する・しないの選択に対応
• Virtualルータ
• ポン付け増設によるスケーラビリティ対応

"なんらかのデータベース"って具体的には？

• データ操作ライブラリ
• BerkeleyDB
• QDBM
• CDB

• いわゆるSQLを使う(R)DB(M)S
• 商用
• SOLID ... IM/File-RDBMS
• Birdstep ... IM/File-RDBMS
• Empress ... IM/File-RDBMS
• FastObject ... IM-ODBS
• 非商用
• FastDB ... IM-ODBS
• SQLite ... IM/File-(R)DBMS

基本番号

「基本番号を上流できちんと検討しよう」と
「モデリングを重視した設計をしよう」≒「今回無理やりUML使うぜ」は
言葉は違うけど、目指している理想は同じ。

つまり、
「スパゲッティは、いやだ」
＝「可読性、可管理性、可変更性の高いソフトをつくりたい」