 |
|
| 土日に極める「データベース秘伝書」 |
【参の巻】データベースの動向と対策を考える
2007/7/20
|
|
|
前のページ 1 2
|
| SQL Serverを安定運用する秘訣
|
SQL Serverは商用データベースの中でも大きなシェアを占めており、それは導入に関して高機能かつ低コストながら簡単で使いやすいという特徴があることから、比較的小規模な環境で多数利用されてきたためだ。
しかし最近ではエンタープライズシステムにおけるデータベースとして注目されるようになっている。小規模から大規模まで、なぜ幅広く利用されているのか。ここでは改めてSQL Serverの持つ利点や機能を振り返って、SQL Serverを理解することができる記事を紹介する。
SQL Serverイントロダクション
第1回：入門者向けにとどまらないSQL Serverの魅力
著者：イー・キャッシュ 伊賀 麗佳、小関 茂徳
SQL Serverは非常に高度な管理機能やデータを活用するための機能が豊富に備わっています。このため、通常のアプリケーションやシステムから、可用性を求められるエンタープライズシステムまで広範囲をカバーできるデータベースとなっています。今回は、このSQL Serverの特徴や機能について紹介します。
SQL Serverではこれらの管理ツールとして「SQL Server Management Studio」が用意されています。SQL Server Management Studioは、これまで説明してきた機能をGUIベースで設定できるツールで、日々のメンテナンスはもちろん、障害発生時の問題処理、復旧作業、また障害対策などのあらゆる設定をこのツールから行うことができます。
他のデータベースソフトでは、GUIツールがなかったり、設定する内容によっていくつものツールを利用しなければならなかったり、操作がわかりづらいなどの問題があります。しかしSQL Serverでは、基本的に管理ツールはこのSQL Server Management Studioに集約されており、操作面でもウィザードなどが多く採用されていたりと、わかりやすさや運用のしやすさなどが重視されている優れたツールとなっています。
先週から引き続き好評を得ている連載が「Windows Vistaで発生するデータベーストラブル対応指南」だ。Vista環境に移行した際に発生する文字コードのトラブルについて、実際のテストを交えながら解説を行っている。
第2回〜第3回ではSQL Server 2005を例に、データの保存や検索などのテストを実施し、その結果や問題の起きる原因を追及している。まず第2回では、問題が発生する原因を推測し、それが正しいものなのかデータの格納と取り出した結果を考察している。
Windows Vistaで発生するデータベーストラブル対応指南
第2回：Microsoft SQL Server 2005で必要な対処（前編）
著者：一志 達也
以前からSQL Serverを使ってきた方ならば承知していると思うが、SQL Serverには文字列を格納するためのデータ型が大きく2種類用意されている。1つはchar/varchar/textなど、先頭に「n」が付かないデータ型。もう1つはnchar/nvarchar/ntextなど、先頭に「n」が付いているデータ型である
実は、この「n」が付いている／いないが、今回の話題では極めて重要になる。なぜなら「n」が付いている方はUnicodeをサポートしているのだが、付いていない方はサポートをしていない。言い方を変えれば、「Unicodeを格納したいならば、先頭に『n』が付いているデータ型を使わなければならない」ということだ。
それでは、先頭に「n」が付いたデータ型で、Nプレフィックスも付けてやってみよう。nvarchar型の列を持つ表を作成するためにSQLを実行する。サロゲートペアも含めてJIS X 0213:2004で追加された文字を扱えている。SQL ServerでJIS X 0213:2004に対応するには、先頭に「n」が付いたデータ型を用いると同時に、Nプレフィックスを使わなくてはならないことが証明された。
続く第3回ではデータベースの利用状況では必須ともいえる曖昧検索についてテストを行った結果を掲載している。その結果はどうだったのであろうか。
Windows Vistaで発生するデータベーストラブル対応指南
第3回：Microsoft SQL Server 2005で必要な対処（後編）
著者：一志 達也
技術的にサロゲートペアを扱えるのと、文字として認識して扱えるのとでは、意味合いが異なるということを述べた。文字列を比較条件とした検索処理を行う場合、その文字を正しく認識できていないと結果として正しくないものが戻される可能性がある。では先ほど格納したデータに対して、実際に検索処理を行ってその結果を確認してみるとしよう。
このとおり、条件に一致しないものも含めてというよりも、表に含まれる3行すべてが戻ってきてしまった。これは、サロゲートペアで表現された文字を、SQL Server 2005が認識できないので無視して処理を行うために起こる。今回の実験で使ったSQLの場合、サロゲートペアの文字を無視すると、条件は「%」だけが残るのですべてのデータにヒットしてしまうのだ。
SQL Serverを使ったアプリケーションをJIS X 0213:2004に対応させようとするとアプリケーション側の変更は避けられない。TempDBを使っている場合には、照合順序の変更のために、SQL Serverの再インストールということにもなるだろう。さらには、自己責任での関数作成と運用まで必要となり、開発者の負担はあまりに大きい。
単にプログラム内の文字列置換えではないかと思った方はシステムの品質保証について考え直した方が良い。アプリケーションのコードに変更を加えたら、システム全体の再テストを行わないと品質の保証なんてあったものではないだろう。しかも今回のケースでは様々な文字列でのテストも求められることからも、テストケースは実に複雑なものになるのを避けられないのである。
来週公開予定の第4回ではOracle Database 10gでのテストが掲載されるので、データベース技術者は忘れずにチェックしてほしい。
|
| さて来週の公開記事は？
|
第4週目からは、PowergreSQLやDB2など注目のデータベースに関する新連載や、運用時には欠かせない管理ツールなどを取り上げた記事が予定されている。乞うご期待！
|
前のページ 1 2
|
|
|
|
|
