SQLiteの仕組みがピンときません

Question

SQLiteはDBサーバにアクセスするわけではなく、それぞれのアプリケーション内にデータベースを保持することができる？みたいな説明をみたのですが、

たとえば、
パズドラのようにモンスターがたくさんいるゲームを作るとして、DBサーバにアクセスするようにアプリを作るとしたら、1つのサーバにモンスターの情報を置いておけばいいと思うのですが、

アプリケーション内にデータベースを作るとすると、アプリの初期化の際に、テーブルを作って、それぞれのモンスターの情報を入れてっていうのを毎回やらなければならないのでしょうか？

モンスターの話はたとえなので、そもそもモンスターの情報はデータベースに置くものではないのかもしれませんが(実はここも知りたい)

とりあえず、SQLiteをアプリ内で使う情報のデータベースとして用いる場合は、アプリの初期化の際にデータベースを作る処理が必要なのか？ということです

よろしくお願いします

Answer 1

深く考えなくてもローカルのファイルに保存するのと同じです。
オフラインのゲームで、データベースを使わない場合はモンスターのデータはXMLや独自データの形で保存しているかと思います。(プログラムオンコードで一緒にコンパイルされている場合もあるかも知れませんが...）
そのデータを代わりにSQLiteに保存しているだけです。

問題はfileでいいのになんでDB?ってとこだと思いますが
DBの強みは
・追加の保存や削除が容易なこと
・数が増えても管理が容易なこと
・数が多くてもデータの検索や集計が容易で高速なこと
・管理、集計、検索、抽出のプログラムを自作しなくても、SQLで比較的低コストで代替できること
・データのゲームプログラム以外からの参照や改変が困難なこと
などです。上のような利点が不要ならわざわざDBを使う意味はありません。

無尽蔵に増えていく、例えば戦績のログなどはDBに登録すると便利です。
モンスターのデータも追加/削除/変更した際DBのデータだけ配布ですむかも知れませんし
数が多い場合は、やはりDBに登録しておいたほうが抽出が楽だと思います

SQLiteをアプリ内で使う情報のデータベースとして用いる場合は、アプリの初期化の際にデータベースを作る処理が必要なのか？

といったわけですので、モンスターのデータなどはあらかじめ登録した状態で配布すると思います。
プログラムが起動するたびにテーブルを構築して、終了と同時に破棄などはあまりやらないと思います。
モンスターやアイテムの取得テーブルや、個別のEXPや能力のテーブルも、空のテーブルをあらかじめ作成しておいて、ゲームプログラムではそこにデータを追加/削除していく。
セーブデータや、得点、戦績の保存なども、テーブルはあらかじめ空のものを作成した状態で配布していて、データの追加だけプログラムから行うのが普通だと思います。

Comments

[akamakku]

>あらかじめ登録した状態で配布
これはアプリ内で行うのではなくて、パソコンで何かしらのソフトを使って、SQLiteのファイルを作るということですか？

[hirohiro]

そですね。
開発環境で作った構成をSQLダンプしておいて、起動時に必要なテーブルやデータが存在するかチェックして、無ければ生成するSQLを実行する感じ？
※ちょっと書き直しました。

Answer 2

他の多くのDBMSは、利用するプログラムは、DBMSのプロセスとTCP/IP通信でやりとりしますが、SQLiteは、利用するプログラムと、DBMSの機能を通常のファイル読み書きサブルーチンと同じように呼び出して使います。

その他は他のDBMSと同じなので、テーブル作成などのタイミングややり方も他のDBMSと全く同じで、何も特別なことはありません。強いて言えば、排他制御の単位がDB全体と広いこと。

ということで、

それぞれのアプリケーション内にデータベースを保持することができる？

という理解は間違っています。データベースはあくまでファイルで、アプリケーション間で共有できますし、永続します。

Answer 3

自分はパズドラをやらないですし、インストールもしていないので実際のところは分かりませんが、
数多くのモンスターがいても、データは大まかに分けて下記の２種類じゃないでしょうか？
・データは名前やファイル名などの文字列データ、HPや経験値のような数値のデータ
・戦闘やイベント表示用の大きい画像、アルバム？の一覧表示のようなサムネイル画像

SQLiteについて
SQLiteはAndroid以外でも利用されていますが、
Androidでは標準で組み込まれているデータベースです。
このデータベースはアプリの起動で毎回フラッシュされるわけではなく、
dbファイルとして端末の中に残ります。
（アプリ設計として毎回フラッシュするように作成することもできます。）

データ項目はアプリ設計者がアプリに必要なものを考え、項目を増やすわけですが、
文字列や数値、日付のデータの様にほかにblob(Binary Large OBject)という型で
画像のような大きいデータも一応は格納できることにはなっています。

が、実際はそれほど大きいサイズは入らないです。直接SQLiteに格納しようとすると、
すぐOOM(Out Of Memory) Errorが発生します。

画像保持に関するアプリ設計について
先述の理由から、画像を多く使用するアプリは
「Http経由で画像をダウンロードして格納する」という様なことがされていると思います。
一度ダウンロードした画像は通常、再ダウンロードしないようにし、
アップデートがある場合は追加更新分だけダウンロードしたものを、
そのアプリ専用のフォルダに格納しているのだと思います。
「もちろんWebから起動のたび/必要になるたびダウンロードする」という設計もありますし、
動画ファイルなどは「ファイルサイズが大きいので"Now Loading"を表示して、
毎回Webからダウンロードしている」という事もあるかもしれません。

結論

画像ファイルをどのように扱うかは設計次第。（当たり前ですみません）

ただし、SQLiteに画像を直接格納して保持し続けることは考えにくい。(メリットがない)
下記、いづれかの方法、及び、併用した方法が採用されているのでは？
・インストール時(パッケージに容量制限あり)、初回起動時、アップデート時に一気にダウンロード
（アプリ容量がとても大きくなる＆初回起動時に長時間の待ちが発生する）
・毎回サーバーからダウンロード（ユーザーにはストレス？）
・必要な時に必要なファイルだけダウンロード（プレイ中、常にネットアクセス）

以上、長文、乱文にて失礼しました。
ご参考になりますでしょうか？