回答編集履歴
4
追加修正
answer
CHANGED
|
@@ -8,7 +8,7 @@
|
|
|
8
8
|
・数が増えても管理が容易なこと
|
|
9
9
|
・数が多くてもデータの検索や集計が容易で高速なこと
|
|
10
10
|
・管理、集計、検索、抽出のプログラムを自作しなくても、SQLで比較的低コストで代替できること
|
|
11
|
-
・データのゲームプログラム以外からの参照が困難なこと
|
|
11
|
+
・データのゲームプログラム以外からの参照や改変が困難なこと
|
|
12
12
|
などです。上のような利点が不要ならわざわざDBを使う意味はありません。
|
|
13
13
|
|
|
14
14
|
無尽蔵に増えていく、例えば戦績のログなどはDBに登録すると便利です。
|
3
追加変更
answer
CHANGED
|
@@ -8,6 +8,7 @@
|
|
|
8
8
|
・数が増えても管理が容易なこと
|
|
9
9
|
・数が多くてもデータの検索や集計が容易で高速なこと
|
|
10
10
|
・管理、集計、検索、抽出のプログラムを自作しなくても、SQLで比較的低コストで代替できること
|
|
11
|
+
・データのゲームプログラム以外からの参照が困難なこと
|
|
11
12
|
などです。上のような利点が不要ならわざわざDBを使う意味はありません。
|
|
12
13
|
|
|
13
14
|
無尽蔵に増えていく、例えば戦績のログなどはDBに登録すると便利です。
|
2
追加修正
answer
CHANGED
|
@@ -11,11 +11,12 @@
|
|
|
11
11
|
などです。上のような利点が不要ならわざわざDBを使う意味はありません。
|
|
12
12
|
|
|
13
13
|
無尽蔵に増えていく、例えば戦績のログなどはDBに登録すると便利です。
|
|
14
|
-
モンスターのデータも追加した際DBのデータだけ配布ですむかも知れませんし
|
|
14
|
+
モンスターのデータも追加/削除/変更した際DBのデータだけ配布ですむかも知れませんし
|
|
15
15
|
数が多い場合は、やはりDBに登録しておいたほうが抽出が楽だと思います
|
|
16
16
|
|
|
17
17
|
> SQLiteをアプリ内で使う情報のデータベースとして用いる場合は、アプリの初期化の際にデータベースを作る処理が必要なのか？
|
|
18
18
|
|
|
19
19
|
といったわけですので、モンスターのデータなどはあらかじめ登録した状態で配布すると思います。
|
|
20
20
|
プログラムが起動するたびにテーブルを構築して、終了と同時に破棄などはあまりやらないと思います。
|
|
21
|
+
モンスターやアイテムの取得テーブルや、個別のEXPや能力のテーブルも、空のテーブルをあらかじめ作成しておいて、ゲームプログラムではそこにデータを追加/削除していく。
|
|
21
22
|
セーブデータや、得点、戦績の保存なども、テーブルはあらかじめ空のものを作成した状態で配布していて、データの追加だけプログラムから行うのが普通だと思います。
|
1
追記
answer
CHANGED
|
@@ -12,4 +12,10 @@
|
|
|
12
12
|
|
|
13
13
|
無尽蔵に増えていく、例えば戦績のログなどはDBに登録すると便利です。
|
|
14
14
|
モンスターのデータも追加した際DBのデータだけ配布ですむかも知れませんし
|
|
15
|
-
数が多い場合は、やはりDBに登録しておいたほうが抽出が楽だと思います
|
|
15
|
+
数が多い場合は、やはりDBに登録しておいたほうが抽出が楽だと思います
|
|
16
|
+
|
|
17
|
+
> SQLiteをアプリ内で使う情報のデータベースとして用いる場合は、アプリの初期化の際にデータベースを作る処理が必要なのか？
|
|
18
|
+
|
|
19
|
+
といったわけですので、モンスターのデータなどはあらかじめ登録した状態で配布すると思います。
|
|
20
|
+
プログラムが起動するたびにテーブルを構築して、終了と同時に破棄などはあまりやらないと思います。
|
|
21
|
+
セーブデータや、得点、戦績の保存なども、テーブルはあらかじめ空のものを作成した状態で配布していて、データの追加だけプログラムから行うのが普通だと思います。
|