最近「SQLServer」を使う機会がありましたので、どうせならメモ的に書き留めておきたく思いました。
「SQLServer」は「Oracle」と比較すると、アホほど簡単なようです・・・・・。
 「Microsoft Access」との相性の良さ 「SQLServer」をやってみて驚いたのは、「Access」との連携プレイの良さでした。 こりゃもう、メチャメチャ便利っぽいですよ！  「新規作成」メニューから、「プロジェクト（既存のデータベース）」を選びます。 （このパターンでAccessを開くと、拡張子adpのファイルが出来ます。）  上のような画面が出てくるので、適当な値を入れます。 一応断っておきますが、「localhost」（ループバック・アドレス）と入れたのではこのファイルをリモートクライアント からは使えませんからね。 当たり前ですけど・・・。 （上のはあくまで「例」です。 適宜、ご自分の環境に読みかえてください。） ※リモートクライアントには、「SQLServer」のクライアント機能を入れなくても繋がります。 (windowsで認証可能なPC間なら。) が、クライアントに「SQLServer」をインストールすると、「SQLServer認証」で接続できます。 「SQLServer・クライアント」を入れないと繋がらないのですから、これはそれなりにセキュアなシステムであると 思われるのですが…。 「sa」というのは、「Oracle」で言うところの「system」ユーザみたいなもんです。 「System Administrator」の略だったかな…？  まあ、こんな風に「SQLServer」のテーブルが、ローカルのテーブルであるかのようにして、見えています。 そしてそれは、このファイルをクライアントマシンから開いても、同様です。 そして更に驚いたことには、以下の手順を（順に）行ってみた結果を見たときでした。 ①京都テーブルを「SQLServer」上に作成。 ②adpファイルを作成し、クライアントに転送。 ③東京テーブルを「SQLServer」上に作成。 ④②で転送していたadpファイルをクライアントから立ち上げてみたところ、東京テーブルが見えていた。 adpファイルは立ち上げ時に「認証」画面が出てくるのですが、この認証時にサーバと同期を取る仕組みのようで す…。 この現象は、実はクエリでも同様です。 しかも、adpファイルでのクエリは、その実態は「SQLServer」の「ビュー」ということのようです。 例えば、adpファイルを立ち上げて、  京丹後市のデータのみ抽出するビューを作成してみたところ、  「Enterprise Manager」で見ても、いつの間にか同じ名前の「ビュー」が出来ていました。（＾＾） ということは、「Access」のクエリが、サーバサイド・クエリとして機能するということなんでしょうね。 ・・・なるほどこれは便利だ…。 （注意点） とは言え、注意点があります。 「SQLServer」のテーブルを何の気なしにadpファイルと関連付けた場合、adpファイルからDML文の発行が出来ません。 これはどうやら、テーブルに「主キー」を設けていないとダメ、ということのようです。 （Accessでなら「主キー」なんぞ設けていなくともそこそこ動くのですが、「SQLServer」はその点、厳格に出来ているよ うです。） ですから、上記、東京・京都各テーブルの場合も、主キーを設けるか主キーと成り得るカラムを追加してやる必要があり ます…。 コンソール 「SQL*Plus」のようなもの、です…。 「クエリアナライザ」というのがそれのようです。  注意していただきたいのは、画面中央ツールバーのところ。 データベース名をきちんと指定しないと、SQL文を認識してくれません。 （そりゃそうです…。 どのスキーマのオブジェクトだか分かりませんからね。） なお、セミコロンはあっても無くても構いません。 この辺りは「DB2」も確か同様でした…。（「DB2編」も構想中。） コンソールでselect文を叩いてみて、一つ気づきました。 「SQLServer」のテーブル名の規則として、最初に数字が来るのはダメみたいです。 （そう言えば確か、Oracleにも同様のルールがありましたネ。） 今から思えば、Excelからのインポート時、テーブル名の頭に“$”が勝手に付いたりしていたのは、それが原因だっ たのでしょう。 ・・・・・「なら、テーブルのインポート時にエラーを返してくれよ！」 という気持ちもありますね。 select * from 26kyouto ではエラーになるので、テーブル名を変更し、 select * from kyouto としてみたところ、上記のような結果が返ってまいりました。  update tokyo_kaitei set F3 = 999 WHERE ﾁﾖﾀﾞｸ = ﾁﾖﾀﾞｸ とやってみた結果。 （3228件のデータですが、一瞬で結果が返りました。） ちなみに、キーが付いていなくても、クエリアナライザからのDML文は全然問題なしです。 （問題ありなのはAccessからのリンク時のみか・・・。 「Access2002」から行ってみたからかな？ 「SQLServer20 00」は「Access2000」に最適化されて作られているような気もしますし・・・。） バックアップ バックアップも簡単です。 GUIで簡単に設定することが出来ます・ また、「定期バックアップ」設定も至って簡単です。 チェックボックスにチェックを入れるだけです。 「ARCServe」や「NetVault」などのバックアップソフトを使う必要もありません。 至れり尽くせり、です。 手動でバックアップする際は、「Enterprise Manager」画面から、該当データベースを右クリック→すべてのタスク→データ ベースのバックアップ でOKです。 バックアップ・ファイルを復元に用いる場合は、該当データベースを右クリック→すべてのタスク→データベースの復元 とします。 バックアップを取ったサーバと復元するサーバが別である場合には、少しだけ注意点があります。 「SQLServer」のインストールパスが違うと、この手順では復元出来ません。 まあ、「オプション」タブを開いて修正すれば良いだけなんですけどね…。 バックアップの種類については、「フル」・「差分」、および「トランザクションログ」のバックアップが出来ます…。 …ものの本によると、「Oracle」や「DB2」には存在する「アーカイブログモード」が、「SQLServer」においては「トランザクション ログ・バックアップ」に相当するのだそうです。 （なんか、無理矢理納得させられているような気がしないでもない。 「Oracle」や「DB2」の更新履歴情報管理の仕組みは、 「SQLServer」より数段凄いと思うのですが・・・。） ・・・バックアップについては、またいずれ追記します。 感想 こんなに簡単で、しかも高機能だったら、『「Oracle」なんて要らんやん！』という感じですね。 まあ、実際どの程度のパフォーマンスを発揮するのかについては（まともなデータを搭載してないんで、）不明ですが。 ただ、あまりに使い勝手が良すぎるので、玄人が敬遠しそうなソフトではあります。（やり甲斐がなさそう…。）  |