written: 2006-03-14 .. 2006-12-26

SQL に関するあれこれ

複式簿記システム | Perl/CGI で MySQL データベースを扱う上での注意点 | Webookmark

プログラミングに DBMS の利用を導入することの興味深い点

データベースのことを知らないでプログラミングをしていると、プログラムで扱うデータをすべてプログラマが自前で管理することになります。メモリ上に存在する変数のデータはプログラム内で管理するのが当然ですが、ファイルに保存するような恒久的なデータの管理が発生する場合には、その管理方法を考えることは（とりわけ筆者にとって）それなりに悩ましい問題でした。例えば筆者はこれまで CGI プログラミングでアクセスカウンタや掲示板などを作成してきましたが、それらのデータをどのような形式でファイルに蓄積するかが、一番の悩みどころであり、また、新しい機能を実現しようとするたびに、古いデータファイルとの互換性は切り捨てざるを得ませんでした。

ところが、データの蓄積に関して、DBMS 利用を前提にしてプログラミングした場合、プログラマは DBMS に対して SQL を通じた操作を考えるだけでよく、実際の物理的なファイルの問題から解放されることになります。いわゆる「ANSI/SPARC ３層スキーマ」における「内部スキーマ」による「物理データの独立」というのはこれのことなのでしょう。

(2006-12-26)

入門書紹介

高橋麻奈『ここからはじめるデータベース』（東京都、日本実業出版、2000-04-30）

RDBMS の入門書の中で最良の本だと思います。致命的ではないものの誤記があってちょっとわかりにくくなっている場所が数カ所存在するのが残念なので、ここに記しておきます（この本は良い部分が多いだけに余計に誤記部分が目立ってしまうわけです）。

ストアドプログラム（p. 20, 56, 148, 149）: 本書では、「ストアドプログラム」の用語を用いているが、どちらかというと「ストアドプロシージャ」の方が一般的かも。
図（p. 79）: 「単価の大きい順に並び替える」と見出しの書かれた表の右横に「降順」と書かれた矢印があるが、これは下から上に向かう矢印ではなく、上から下に向かう矢印として表した方がわかりやすいかも。著者はおそらく値の並ぶ方向を矢印で示したかったのでこのように示したのだと思われるが、矢印の側に「昇順」「降順」という言葉を付記すると、この矢印の方向に沿って「昇る」「降りる」と考えたくなるため、矢印の方向を訂正するか、それとも矢印の側の「昇順」「降順」の付記を削除するかのどちらかにした方がいいように思われる。
「2つの表で重複する行が除かれず、1つずつの行として得られます。」→「2つの表で重複する行が除かれます。」（p. 90）: 著者公認の誤記。またこの訂正の結果、後続の「重複する行を除きたい場合は、ＤＩＳＴＩＮＣＴを指定します。」の説明文も不要になり削除すべき箇所となる。
図（p. 93）: 図中の SQL 文では列名に表名を付記して「売上明細 . 商品コード」という風に記述している部分が何ヶ所かあるが、表名（売上明細）の修飾は不要かも。もちろん修飾しても問題はないが、この表の中で修飾している場合と修飾していない場合とが混在していて統一されておらず、初心者には誤解・混乱の種となるので、余分なものはできるだけ省いた方が無難と思われる。
ちなみに、表名の付記が必要となるのは、FROM 句の中に複数の表名をカンマ（，）で区切って列記するような場合や、次のページ（p. 94）で説明されているような「相関副問合せ」の中で主問合せ側の列名を使うような場合である。
「ＳＥＲＩＡＺＡＢＬＥ」→「ＳＥＲＩＡＬＩＺＡＢＬＥ」（p. 112）: 英単語の綴りの誤記。
図（p. 132-133）: 真ん中の図「権限を移譲する」の中でユーザＢが 2 人描かれているが、下側のユーザＢは人物イラストとともに「ユーザＡ」の間違い。