既存の pdb2 レイヤーの下に、SQLite を用いた DB レイヤーを設ける。
アプリケーション側のインタフェースは pdb2 に似た pdb3 レイヤーを設ける。
実装は Bridgeroot で行う。
pdb3 は DB で実装されるため,SQL テーブルが基礎となる.
ここでは各テーブルのスキーマや役割などについて解説する.
user-id | element-id | mode-id | log-id | daily-id | |
初期状態(最初の起動時) | x | x | x | x | x |
ユーザ名設定後 | o | x | x | x | x |
問題集選択後 | o | o | x | x | x |
モード選択後 | o | o | o | x | x |
学習前 | o | o | o | △(仮設定) | △(仮設定) |
学習後 | o | o | o | o(仮設定IDでinsert) | o(仮設定IDでinsert) |
学習前は log-id の最大値を log_id table から取得し,仮設定する. 学習後は insert する.
daily-id についても同様.
学習管理クラス CTransDlg より DailyLog (daily_log + daily_question_log) を得る.
pdb2 と pdb3 の互換性について.
pdb2 では各問題の履歴に「前回の不正解フラグ」と「前回の学習フラグ」が存在した. これらは各問題が所属する問題集を最後に学習したとき(前回)に,その問題を学習していたか,不正解であったかを記憶するフラグである.
pdb3 においては各問題が問題集とは独立した存在であるため,問題の履歴に「問題集に対する参照を伴う履歴情報」を載せることはできない. 従って,これらの履歴情報は別の形で実装する.
まず,「学習毎の履歴」に「どの問題を学習したか」という情報を付加する.実体は daily_questions_log である.「前回」の「学習毎の履歴」を特定することは daily_log を参照すれば容易に実現できるため,「最終不正解問題」や「最終学習問題」は daily_questions_log のサブセットとして実現される.
但し,履歴の移行時にはこれらの情報は切り捨てられる. これはフラグによる情報は daily_questions_log よりも情報量が少ないためである.
学習毎の履歴について、pdb3 では各回で学習した問題IDとその履歴を保存する。
このため、pdb3::DailyLog には正解数と不正解数のカウンタがなく、その下に含まれる pdb3::DailyLog::DailyQuestionLog の正解数、不正解数を集計することで「学習回での正解数、不正解数」を取得することになる。
履歴の pdblog2 -> pdb3 への移行時には、pdblog2::DailyLog には学習した問題群と履歴が存在しないため、仮想的に qid=0 の問題を追加し、その正解数、不正解数に「学習回の正解数、不正解数」を保存する。
従って、DailyQuestionLog を利用する際には、qid=0 のものは基本的に無視する必要がある。
このような移行を行うのは,pdb3 への移行後に「正解率推移グラフ」が消えると移行時に情報が大きく失われたように(PSS の UI 上)見えてしまうためである.
folder テーブルに名前を付けたもの。
CREATE VIEW v_folder AS SELECT e1.name AS 'name', e2.name AS folder FROM folder, element_info AS e1, element_info AS e2 WHERE folder.id = e1.id AND folder.fid = e2.id
INSERT INTO question VALUES(NULL,'zero','0','h','desc','w.wav','')
NULL を許可している INTEGER PRIMARY KEY に NULL を指定すると、auto-increment が行われる。 で、その際の値は sqlite_last_insert_rowid() で取得できる。
このことから、おそらく実装としては rowid をそのまま INTEGER PRIMARY KEY に使っているんだろう。