自分向けの想定問答

ID全面導入は、コード体系の分析を手抜きできてしまうので、相当分かってる人がやらないとやばい: 設計のできない人が作るモデルは複合主キーだろうと関係なくやばい。むしろ、複合主キーでない方が復活が容易（プログラムの修正工数が減少するから）。業務わかってる人ならどっちでも大丈夫。
IDによって設計が簡単になるというのは、よく分からない: 常にIDをつけることで何を主キーにするべきかという判断をしなくてよいと言う小さなメリットがある。DRYだ。実際問題として履歴を持つようなテーブルでユニーク制約をつけない選択ができるというのは結構なメリットだと思う。
サロゲトーキーって「テクニック」丸出しなのに、イベントのIDなんて重要な意味をもつものと同じ形をしてるなんておかしい: ID導入時のイベントIDはまったくもって重要ではない。だってポインタだぜよ。ポインタを画面に表示する奴なんておらんでしょうに。イベントIDを画面に出したいなら、そのときは「表示イベントID」みたいなカラムを追加してユニークキーをつけませう。
対照表にもIDを付けるべきか: どうなんでしょうね。ruby on railsはつけない方針みたいだけど。私は着けた方がいいと思う（ポインタだから）。

そもそもデータベースの制約って、完璧から程遠いわけだし、実際のアプリではデータベースのエラーをそのまま表示なんてしない。当然、アプリ側でもデータベース上の制約以上のものをプログラムで記述する。とゆうことは、データベースの制約なんてものは最後の砦以上のものではないのだよなぁ。

そう考えると、T-ERによる設計なんていうのはその程度のことしかできないということも言えるのかも（←おそらく言いすぎ）。まだ、設計論の良し悪しまでは踏み込めるほど見解が固まってないので、今はこんなところで止めておこう。