[[PSSdev]] #contents * 概要 ** SQLite を使った実装 既存の pdb2 レイヤーの下に、SQLite を用いた DB レイヤーを設ける。 アプリケーション側のインタフェースは pdb2 に似た pdb3 レイヤーを設ける。 実装は Bridgeroot で行う。 * テーブル pdb3 は DB で実装されるため,SQL テーブルが基礎となる. ここでは各テーブルのスキーマや役割などについて解説する. - [[./テーブル]] * 実装 ** 各IDの有効範囲 ||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 上)見えてしまうためである. * ビューの例 ** v_folder 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 * その他 ** auto-increment in question table 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 に使っているんだろう。