itemanblr.

原理の意義は、その持続力にある。対照的に、製品やテクノロジは（その意味ではSQLも）絶えず変化するが、原理は変化しない。たとえば、Oracleを知っているとしよう。いっそのこと、Oracleのエキスパートであるとしよう。だが、Oracleが知っていることのすべてであるとしたら、その知識をDB2やSQL Serverの環境でも応用できるとは限らない（逆に、既得の知識が新しい環境での理解の促進を妨げることも考えられる）。しかし、基本的な原理を知っているとしたら、つまり、リレーショナルモデルを理解しているならば、ほかの環境にも応用できる知識やスキルを有していることになる。その知識やスキルをすべての環境で活かすことができるし、それらが古くなることはないだろう。

- データベース実践講義 ―エンジニアのためのリレーショナル理論 (THEORY/IN/PRACTICE)p.3 1章 概要 1.2 製品ではなく原理である

そういうわけなので、最初から単独主キーだけでＤＢ設計を進めるクセをつけてはいけない。関数従属要件の取りこぼしを避けるためだ。すなわち、まずは複合主キーを含めた形で論理設計を誠実にまとめる。その後で、実装環境に合わせてサロゲートキーを必要に応じて組み込む。そんな設計手順が「無難」だ。

- サロゲートキーの事例解説: 設計者の発言

データベースシステムには「複雑さの保存則」のようなものがある。「データ構造の複雑さ」と「データ処理の複雑さ」の総量は一定である。つまり、同一のデータ要件において、データ構造を単純化すればデータ処理が複雑化する。たとえば私の言う「森羅万象テーブル」は、たったひとつのテーブルでシステムの全データを保持しようとするチャレンジングな設計スタイルなのだが、これほど「ベストっぽいシンプル」なＤＢ構造はない。しかし、そのデータ処理様式の複雑さは想像に余りある。

- サロゲートキーは強制されるべきものではない: 設計者の発言 (via hidenorigoto)

カラム指向もRDBに取り込まれているので、最終的に残るのはデータモデルとそれを扱う言語、それらを支える代数や論理などの理論的基盤ではないでしょうか。表面的にどのデータベースを選択するかはプロジェクト単位では重要な意思決定ですが、技術者としてはそれより長期的な視点で見たほうがいい

- Twitter / @Masayoshi Hagiwara