今年度のDBゼミで感じたことを書きます.いくつかはゼミ中でコメントしましたし,いくつかは私以外のだれか(教員または先輩)が発したものですし,いくつかはゼミでは出ていなかったものです.
DBMSになる
予想外の質問があったときに,グループ内で検討して,結論を出すというのはいいことなのですが,それが多すぎると,解答待ちの時間が長くなってしまい,ゼミは非効率になります.
発表グループは,データベース管理システムとして振る舞うこと.これが理想です.
質問があればとりあえずすぐに答える.「打てば響く」ってやつですね.
もしそこで,おかしな応答になったとしても,質問者つまりクエリを出す人が,修正だとか,絞り込むだとかいった形で,質問をし直してくれます.DBMSに扮する発表者は,それに即答すればいいのです.
いろいろな質問が来ても,うまく,とりあえず答を出すためには,発表準備が重要になります.スライドを作るだけでなく,それぞれのスライドで何を話すか,スライドとスライドのつなぎに説明が必要ではないかとか,そのスライド内容でどのような質問が来そうかを,あらかじめ入念に検討しておくわけです.どの質問にはだれが答えるといった分担も,決めておくといいですね.
これは,データベースでいう前処理に当たります.
とはいえ,前処理したら終わりというわけではありません.ゼミの質問は,SELECT文であるように見えて,UPDATE文やDELETE文のように,発表内容やこれからの活動に影響を与えることもよくあります.
そういうのは素直に取り入れ,そのたびデータベースの中身を変えていきましょう.
「〜できる」という仕様
仕様に,「〜できる」と書かれていれば,「〜」の行為をするか,しないかを,その主語に当たる人が選択することを意味します.
ということで,する場合としない場合の両方を検討しないといけないことになり,設計・実装の側に手間を要することになるのは,注意してくださいね.
脱線しますが,プレゼン資料や何らかの文章を書いていて,名詞+「することができる」と書いたら,途中の「することを」を取り除いて,それで読みやすく言いやすいか見直してください.たいてい,名詞+「できる」のほうが良くなります.さらに字数を減らすなら,名詞+「可能」というのもありますが,このときは,読みやすくなるとは限りません.
フラグはいつ立てるか
「〜フラグ」という属性を書くのは,その必要性があるのならかまいませんが,いつ「立てる」,すなわちtrueにするかの検討を忘れないようにしてください.
何らかのアクションを起こすのと同時に「立てる」のなら,問題ないのですが,イベントの20分前に「立てる」ことにするのなら,サーバでタイマを持っておく必要があります.定期的に処理をするソフトウェアとしては,Linuxなら,cronというのが有名です.
ただ,毎分その処理をする必要があり,またデータベースに登録するレコードが多くなることを想定するなら,サーバに負担がかかりますので,cronを前提とする設計や運用というのはできれば避けたいもので,結局のところ,設計レベルでは,何らかのSQL文と同時に,UPDATE文でフラグを立てるようにすべきなわけです.
質問対象を特定する
設計の特定の属性に着目して,質問したいという人は,「スライド番号なになにの,これこれテーブルにある,属性どこどこについて」というように,スライド番号・テーブル名・属性名を,質問者から見て分かるよう…特定できるように,指摘してください.
さらに言うと,もし,議論をしていって,あるテーブル名や属性名の名称がまずいと分かって変更した,ということがあれば,その変更したテーブル名・属性名に対して質問するときには,「今〜と書かれている」と,書かれているものを言うことで,誤解なく伝わるはずです.名称が変わったことの確認は,そのあとです.