○「Region」は「Hosted Service」と同じ場所にしておこう

同じRegion(Azureデータセンタの場所)の場合は、データ転送に関する課金は発生しない。　また、オンプレミス等からのアクセスが必要な場合は、レイテンシーが少ないアジア地区を選択する事をお勧めする(つい最近までアジア地区のデータ転送料金は他の地区に比べて非常に割高であった)

○「Edition」はWeb(1GB)から始め少しずつ増やそう

おおよそだが、1GB当り約870 円必要になる。仮にBusiness(50GB)を選んだとすると、いきなり43700円/月の課金が発生する(実際には日割りで算出される)。Editionも容量も後からSQLで変更可能なので必要最低限の容量を確保するようにされたい。

○Databaseの照合順序は「SQL_lation1_General_CP1_CI_AS」固定で変更できない

必要に応じてTable列定義または式レベルで照合順序を意識されたい。

○サーバ時刻はUTCである。

規定値などに利用する場合があると思うが時差を意識されたい。

その他、未サポートの機能などもあるが、ここでは語り尽くせないので必要に応じMSDNや TechNet等を参照してほしい。

図5は、図4で「Manage」を押すと起動できる、SQL Server Management Studio(SSMS)ライクな「Database Manager」だ。これも比較的最近になって提供されたツールで筆者が始めた当時には無かった物だ。

図5 : Database Managerの使用例

このツールでは、テーブルデザインやデータメンテナンス等、ある程度の事が出来るようになっているが、実は筆者の使用比率はあまり高くない。まだ発展途上ではあるが、既にSSMSなどで手厚いサポート機能を使い慣れているユーザーからすると、あまり使い勝手が良くないというのが正直な所だ。

また、現在、筆者はデータ型「uniqueidentifier」を良く使うが、このデータ型を使用しているテーブルは、データメンテナンスが行えないというのも一つの理由だ。

筆者が使うことが多いのは、まずSSMSだ。基本的にはオンプレミスのDBサーバに必要なスキーマを作成し、ここで開発やテストを行う。そして、最終的に図6、7のようにSQL Azure用のスクリプトを作成し反映を行っている。

図6 : SSMSでスクリプト生成を指示

図7 : SSMSのスクリプト生成でSQL Azure向けに変更するよう設定

なぜ、このように回りくどい方法を取るかと言うと、SSMSもVisual Studioも直接SQL Azureに接続する事が可能なのだが、残念ながら現状はGUIでテーブル定義等を行う事が出来ないからである。また、スキーマ変更等が必要な場合もあるがこれも、反映時に変更スクリプトを出力してくれるので、それをSQL Azureに対して適用している。

なお、データメンテナンス等については、図8のようにVisual Studioを使用するケースが多い。Visual Studioではクエリーデザイナを使って作業が出来るので重宝している。

図8 : Visual Studioのクエリーデザイナでデータメンテナンスを行っている例

また、図9は手持ちのAccess2007でODBCを使ってリンクテーブルを用いたデータメンテナンスを行っている様子だ。

図9 : Access2007でデータメンテナンスを行っている例

一例を挙げただけだが、このように既存のツール類を含め様々な方法で利用できるのが、SQL Azureの魅力の一つだと感じている。

なお、SSMSやAccess等で直接SQL Azureに自社内等から接続する場合には、FireWall等での1433/TCPの外部への通信許可と、後述するSQL AzureのFirewall設定が必要となるので注意されたい。セキュリティポリシー等の関係で許可/設定出来ない場合には、http(s)通信のみで利用できる、Database Managerもしくはそれに準ずるサードパーティ―製ツール(例えば、myLittleAdmin for SQL Azure等)の利用が必須となる。