iniをデータベース代わりにしない判断軸

しろまえ殿は、設定ファイルとして便利なiniを、業務データの保存先に使う設計を見直した。 判断軸は形式の好みではない。書き込み頻度、同時アクセス、検索量の三つだ。

iniは設定に向いている。 環境ごとの値を人が読み、アプリが起動時に読む用途なら扱いやすい。 一方、利用者の入力を頻繁に書き戻す用途では弱点が出る。

標準の読み込み関数はあっても、書き戻しは自前になりやすい。 改行や特殊文字のエスケープを誤ると、次の読み込みで壊れる。 同時書き込みも、ファイルロック（同時更新を順番待ちにする仕組み）を自分で組まなければならない。

JSON（構造と型を保ったテキスト形式）は、読み書きの対称性が高い。 ネストも表現できる。 ほぼ読み取り専用で、件数が少ないデータなら移行先として自然だ。

ただしJSONもファイルである。 複数の処理が同時に書くなら、ロックや一時ファイル置換が必要になる。 検索や集計のたびに全件を読み込む設計も、データが増えると苦しくなる。

その段階でSQLite（アプリ内に置ける小さなデータベース）を選ぶ。 トランザクション（複数の更新を一まとまりで確定する仕組み）と検索をデータベース側へ任せられる。 さらに規模や同時接続が増えれば、サーバ型のデータベースを検討する。

たとえば、冷蔵庫のメモならiniで足りる。 家族が同時に書き、日付別に検索し、集計するなら、ノートではなく台帳へ移した方が安全だ。

しろまえ殿は、形式を変える前に用途を分けた。 設定はiniのまま残す。 少量の参照データはJSONへ移す。 更新と検索がある業務データはSQLite以上へ置く。

もう一つ、配置も確認した。 公開ディレクトリ（ブラウザから直接読める場所）にJSONを置くと、URLだけで中身を取得されることがある。 秘密や内部データは公開領域の外へ置き、必要ならWebサーバ側で直接アクセスを拒否する。

しろまえ殿が得た結論は、iniが悪いという話ではない。 設定とデータを同じ箱で扱わないことだ。 用途に合う保存先を選べば、移行も運用も小さくできる。