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