「データ保存形式の選択」
ブラウザゲーム開発初期にまず考えたことが、
どんな方法でデータを保存するか？ということだった。
開発当初はプログラムの知識があまり無かったので（今もだけど）
当時は、保存できれば何でもいいと考えていた。
（ちなみに開発言語はPerlを使用していた）
最初はCSVで保存を考えたが、
少し進めるうちに、これはいくらなんでも非効率であることに気づいた。
そこで、データ保存には何らかのデータベース形式の方法にすることにした。
いくつかその時に考えていたのが、以下の3つだった。
①SQLiteで導入の簡易なRDBMS。
②MySQLなど本格的なRDBMS。
③DBMと呼ばれる非常に簡素なデータベース。
まず②の本格的なRDBMSは最初に選択肢から外した。
理由は扱うデータ量と、構築と運用の難易度のためである。
何万行のレコードの処理ということなら、これしか選択肢はないが、
たかだか最大レコード数500位の個人開発のブラウザゲームには、
大規模なRDBMSは不要と思ったからだ。
で、残ったSQLiteかDBMのどちらにするか悩んだ。
開発ゲームの特性として、データ量は多くないが、
アクセスの負荷はそれなりのものを想定する必要がった。
それで、SQLiteを調べると、
あまり高負荷な環境は適していないということが分かった。
最終的に残ったのがDBMでデータ保存を行うということだった。
DBM(DataBase Management)は、
連想配列に結合してランダムにアクセス可能なファイルシステムで、
連想配列のキーにアクセスするだけで、レコードの追加、変更ができる。
システムそのものが簡素なので、高速に動作することができる事が利点。
ただ、これにもいくつか問題点があって、
①排他制御は全て自前で行う必要がある
②あくまでデータの保存が目的であり、SQL文は一切使えない
③一部のDBMはデータ量が多いとデータを切り捨てることがある
④管理ツールも自前で用意する必要がある
①については、データ処理を行う際、全て排他制御をする必要がある。
これについては面倒と言えば面倒だが、まぁやってやれないことはない。
Perlではflockを使うので、共有ロック、排他ロックも分けられた。
②一番の問題と不便さはこれ。SQL文が使えない事が一番のネックになる。
SELECT文が使えないので、何らかのリストを作る時などが冗長になりがち。
レコード全てを参照し、条件式で振り分けねばならない。
つまりレコードが数が多いと致命的な問題と言える。
ただ今回は最大レコード数もそれほど多くないのでゴリ押しでいった。
レコード数が多いのなら素直にRDBMSを使うべきだろう。
ただリストを作成する必要がなく、
ある一つのレコードを参照するだけ、というのなら有力な選択肢になる。
この場合はレコードが何十万行だろうが、問題ない。
③は使用するDBMによってレコードのデータ量に制限があるので注意。
今回はデータを切り捨てることがないGDBMというDBMを利用した。
④データを管理するツールも全て自作である。
これを作成しないと中身を確認することができない。
しかしDBMにも利点があって、
①かなり強引にデータ操作ができる
②SQLインジェクションの可能性が無い
③挿入するデータには、それほど気をつけないて良い
①はDBMは連想配列の塊なので、
後からデータを無理矢理に付けたそうが、問題ない。
カラムが存在しないので、RDBMSのテーブルの管理よりもずっと緩い。
②DBMにはSQL文がそもそも存在しないので、
SQLインジェクションの可能性はない。
③データ型という概念もないので、どんな値を入れても動作する。
というわけであって、DBMもDBMでそれなりに利点はある。
デメリットを考えて、あまり問題がないなら、選択肢としてはあると思う。