スキーマ実装ってほんとまちまちだな。(若干修正-1)

2005年6月29日コンピュータ

Oracleのところがかなりデムパで無茶苦茶だったので修正。

■運命の逆転/Reversal of Fortune(FD)

いつもいろんな方にこのカードをプレゼントしていただいています。
先日も思いがけない方からこのカードをいただきました。
謝謝！

　_
( ゜∀゜)∩
　⊂彡

　↑実はジョルジュ長岡という名前がついてる以外元ネタとか知りません。
　　ぶっちゃけよくわかりませんが調べる気にもなりません。

■PostgreSQLのスキーマ実装について勉強してみた。

ついでにDBごとのスキーマ実装についても自分なりに比較。
てんでまちまちやんけ・・・・orz。

---------------------

・SQL Server 2000 : スキーマはサポートされてません。
　全てのテーブルやストアドはフラットな空間に作成されます。
　(Yukonではスキーマがサポートされますが動作するPCが無いのでわかりません)
　スキーマが無いので書くことありません。

・Oracle : スキーマ = ユーザ名として実装されています。
　ユーザを作るとユーザ名のスキーマが自動的に用意されるので
　スキーマ名=ユーザ名である限りスキーマを意識して作る必要はありません。
　テーブルやストアドはいずれかのスキーマ(ユーザ)に属していて
　ユーザ名以外のスキーマが欲しい場合新たにユーザを作ることになります。
　ただ、パッケージという機構が用意されているので、ロジックが
　フラットな空間に大量に散在するなんてことにはならなさそうです。

・PostgreSQL : 数時間いじってみただけなのでその程度の理解ですが。
　Oracleと似たようなもんだろうと思ってましたが、PostgreSQLは
　スキーマ = ただの名前空間として実装されているようです。
　ユーザ名とスキーマ名は一致する必要がありません。
　また一つのユーザが複数のスキーマを持つことも出来ます。

　このためユーザ作成直後にはスキーマは存在しませんしOracleの様に
　勝手にスキーマが生成されたりとかもしません。　
　スキーマを作らずにスキーマ名を指定せずにテーブルを作ると
　publicというシステムスキーマにテーブルが作成されます。
　自分の名前のスキーマにテーブルを作りたいなら最初に明示的に
　スキーマを作成してやる必要があります。

　又、PostgreSQLはオブジェクト名の解決の際、検索パスを使用して
　オブジェクト名を解決します。
　デフォルトのオブジェクト検索パスは
　 $USER(ユーザ名)スキーマ→PUBLICスキーマ
　の順になっています。
　(Oracleではログインユーザ名のついたスキーマ内しか検索しません)
　このため特定スキーマの中でDROP TABLEしてもpublicスキーマに
　同じ名前のテーブルが存在してたりすると、うっかりSELECT文が
　通ってしまう可能性もあります。
　(publicスキーマへのアクセス権を剥奪すればいいだけだけどな。)

　逆にいえばSQLServerのようなフラットなスキーマモデルにもOracleのような
　ユーザごとにスキーマが与えられるモデルにも両方化けられるということ。
　混在モデルは検索パスを悪用すれば継承関数のオーバーライドみたいな
　使い方が・・・いいのか？
--------------------

■他
1.PL/SQLについてAdaに酷似してるな〜と思ってたら本当にそういうつもりだったらしい。
http://ja.wikipedia.org/wiki/PL/SQL

2.OracleのようなパッケージがPostgresには無いということに気づく。
「ないからそういうのがほしけりゃスキーマに格納しろ」とか書いてある。
パッケージが無いのでパッケージ内の変数は定義できない。
・・・・というかOracleのPL/SQLが高機能すぎるだけじゃんw
パッケージごとに内部変数もってたりパッケージの自動初期化が出来たり。

Adaのまがい物を根性と意地で実装したのがOracleで、Oracleの真似を
しようとしたけど制御構文くらいしか真似できてないのがPostgreSQL、そう理解した。
そういやMySQL5.0もOracleモドキのストアドを実装する予定と書いてたな。
MySQLはおそらく一生使わないと思うけど。