*
*
READY STATION トップ ＞ READY プライムタイム
*
READY プライムタイム
*
READY STATION だけの特別情報をお届けする「READY プライムタイム」。
*
他では知ることのできない情報やインタビュー、座談会など、毎回、SQL Server 2005 に関するさまざまな情報を掘り下げてお届けするプレミアム企画ページが「READY プライムタイム」です。今回は、ISV (独立系ソフトウェア ベンダ) の皆様をお招きし、ついに完成した SQL Server 2005 への期待や SQL Server を採用し続ける理由、Oracle や オープン ソース (PostgreSQL、MySQL) を選定する余地はないのかなどについて、本音で語っていただきました。 		*
*
*
スペシャル座談会
SQL Server 2005 対応ベンダ (ISV) に聞く
なぜ SQL Server を採用するのか 		*
*
*
**
Index
*
*なぜ SQL Server を採用したのか
*
*SQL Server を採用し続ける理由
*
*SQL Server の GUI ツールは大きな魅力の 1 つ
*
*SQL Server を採用し続けるのは MSDE の存在も非常に大きい
*
*お客様が Oracle を希望した場合はどうしているのか
*
*Oracle の場合はサポートやコンサルティングの価格も考える必要がある
*
*オープン ソースのデータベースを選定する余地はあるか
*
*Access ユーザーへのアドバイス
*
*SQL Server 2005 に期待すること
*
*
座談会の様子
*
【座談会参加者】(写真左から)
*
黒川 明宣 氏   ピーシーエー株式会社 Dream21事業部 部長
*
玉木 栄三郎 氏   トッパン・フォームズ株式会社 情報メディア統括本部 チーフアーキテクト
*
三部 雅法 氏   東芝テック株式会社 流通情報システムカンパニー 商品開発センター ソフトウェア開発技術部 アーキテクト
*
星野 晃一郎 氏   株式会社ダンクソフト 代表取締役 C.E.O. デジタルアーキテクト
*
*
*
*
*
マイクロソフトは日本語処理のノウハウを非常に持った会社 (星野氏)
SQL Server は大変メンテナンスしやすい (玉木氏)
ISV 向けサポートが非常に充実。聞きたいときに聞ける窓口がある (黒川氏)
SQL Server 6.5 以降はようやく安定稼動するようになった (三部氏)
*
―――   まずは皆さんの自己紹介からお願いします。

星野氏   私はダンクソフトという会社で、「ロバート・システム」というパッケージ ソフトを販売しています。我々は利益管理と呼んでいますが、企業の中の基本的なお金の流れ、仕掛かりから受注、仕入れ、発注、請求、入金までの流れを 1 つのパッケージとして一元管理できるのが特徴です。もう 1 つのビジネスとしては、金融系のポータル サイトを関連会社が運営しており、5 年位が経ちます。そういった金融系の、特に証券会社系のビジネスもしています。
マイクロソフト製品は 1980 年代の後半から使い始めて、Windows NT は初期バージョンの 3.1 から、Access も初期のバージョンから採用しています。日本で最初に Access が発売されたときのマイクロソフトのダイレクト メールには、Access 上で動作する弊社製品の案内が一緒に入っており、そのころからデータベースに携わっています。

玉木氏   私はトッパン・フォームズという会社に勤めています。トッパン・フォームズは、凸版印刷の子会社になりまして、地味な会社ですが、おそらく皆さんの家にも 1 つは弊社の製品があるかと思います。たとえば大手宅配会社さんの送り状ですとか、携帯電話やクレジット カード、銀行の利用明細、あとは請求などによくあるバリっとはがす圧着ハガキなどが我々の製品です。そういうものの製造、印刷などをしている会社です。
私自身は、情報メディア統括本部という部署におりまして、IC カードや IC タグ、IC ラベルといった、ポスト バーコードと言われている RFID (Radio Frequency Identification : 無線 IC タグ) 技術を使った製品の取り扱いをしています。IC タグの方はあまり目にはしませんが、IC カードでは FeliCa や Suica、Edy、JAL といったカードを発行して、いくつかの企業に提供しています。
また、マイクロソフトさんと業務提携し、「RFID .NET ソリューション センター」というものを共同で運営しています。ここでは、RFID をうまくハンドリングしていくためのいろいろな技術を、.NET や Windows アーキテクチャの中にインプリメントしていくことを現在行っています。私自身は、そういった中での製品開発や啓蒙活動をしています。

黒川氏   ピーシーエーの黒川です。当社では、パソコン用のパッケージ ソフトという形で、財務会計や PCA 会計というものを中心に、販売、仕入、在庫管理、その他周辺の税務まで、開発、販売しています。また、1999 年からは 21 世紀に向けて「PCA21」というプロジェクトを立ち上げ、「PCA Dream21」という ERP パッケージを開発して 2001 年より販売開始しました。
実は当時、私はシステム開発部におりまして、入社以来 16 年間、PCA 会計の設計、開発に携わってきました。Dream21 では開発部の立場として、特徴と優位性について社内外への普及活動を主に行っていました。「PCA Dream21」は、当時マイクロソフトが提唱していた Windows DNA というアーキテクチャを採用し、すべて COM+ で実装しており、いち早く Web サービス モジュールをパッケージとして発売しています。ただ、そういったメリットを正しく伝えられる営業がいなかったので、「作った本人が売ってこい」ということになりました。そこで 2003 年に Dream21 事業部という部署を作り、そこへ異動して現在に至っています。実は、今でもパートナー様向けの Web サービスのインターフェイスを実装したり、ちょっとした開発を行ったりすることもあります。

三部氏   東芝テックの三部です。流通システム研究所という部署に勤務し、ソフトウェアのアーキテクトをしています。今抱えている製品は、「CrossMission」という .NET の上にアプリケーションを構築するためのミドルウェアです。通常フレームワークというと何層にもなっているのですが、CrossMission は .NET Framework とアプリケーションの間に入るミドルウェアという位置付けです。オープン ソース系ではアプリケーション サーバーがそういった位置付けになるのですが、それらは Web アプリケーションを対象としています。我々の CrossMission は Web アプリケーションだけでなく、クライアント / サーバー型の Windows アプリケーションや XML Web サービスまでを対象とし、すべてをカバーできるような形で出荷しています。

ページのトップへページのトップへ
*
**
なぜ SQL Server を採用したのか
− Access を共有利用するとパンクするのが目に見えていた
− UNIX や Oracle は不便で面倒
− SQL Server は非常に強靭にできている
− 数千以上の店舗へデータベースを導入するには価格も決め手だった
*
―――   次に、皆さんが SQL Server を採用した理由や、それにまつわるエピソードについてお話しいただけますか。

*星野氏
*
星野氏   私どもが SQL Server を最初に採用したのは 1995 年ごろになります。当時は Oracle などの大きめのデータベースは、どちらかというと汎用であるとか、ワークステーション クラスで止まっていて、パソコンのネットワーク上だと覚えている限り 1995 年までは、Btrieve (Novell NetWare) くらいしかまともに動作するものがありませんでした。それ以外の選択肢では Sybase の製品か Access をサーバー上において、みんなが共有するというレベルでした。
ところがそれだと、利用者が 10 人を超えるとパンクするというのが目に見えていたので、どうしようかと考えたときに、当時の SQL Server 6.0 と Windows NT 4.0 という組み合わせを採用することにしました。これが使ってみると非常に良かったので、それ以降はずっと SQL Server 6.5、7.0、2000 と使い続けています。

玉木氏   私個人は、UNIX、Sun、Oracle とずっと使ってきて、周りからは難しいことをやっているように見えて格好いいのですが、いかんせんコマンド ベースなので「不便だなあ」「面倒だなあ」と常々感じていました。その点、Windows は GUI ベースなので本当に便利ですね。会社では、最近は仕様を策定する立場にいますので、「面倒な部分は省いてビジネスに集中しましょう」ということで、積極的に Windows アーキテクチャを取り入れるようにしています。
私自身は SQL Server 6.5 からの個人あるいは法人ユーザーで、SQL Server というよりは Windows プラットフォーム全体を使っています。

黒川氏   SQL Server は、会社としては SQL Server 4.2 から研究を重ねてきましたが、私自身は SQL Server 6.5 から本格的に利用するようになりました。弊社が最初にデータベースに携わったのは MS-DOS の時代で、そのころに会社として OS/2 用のプレゼンテーション マネージャに対応したパッケージを作ろうという話になりました。ただ、まともに使えるデータベースがなかったので、データベースを自社開発したというのが始まりです。しかし、自分たちで 1 から開発するというのは明らかに難しく、非常に面倒でした。
また、1997 年に PCA 会計をリニューアルするときに、Btrieve (NetWare が標準で提供しているデータベース機能) を利用するということで設計がほとんど完成していたのですが、そのころの ISAM 系や Btrieve では処理が多重化してくると、追いつかなくなりデータが壊れてしまうことがありました。また、当時の質の悪いネットワーク カードでは、瞬断などのネットワーク障害時に簡単にデータが飛んでしまったりと本当に苦労しました。
そういった理由から Btrieve では駄目だということになり、設計をすべてやり直して SQL Server を採用することにしました。SQL Server は、私自身は初めてでしたが、使っているうちに便利で非常に強靭にできているということを感じ、現在に至るまで SQL Server を使い続けています。

三部氏   私が SQL Server に携わったのは、最初のバージョンの SQL Server 4.2 からです。それまでは、Sybase や Oracle などを利用していました。
元々の流通系のシステムというのは、本部サーバーやマスタ サーバーにはオフコンを使ったり、ミニコンを使ったりと、どちらかというとファイル系が中心でした。そこから PC を使ったシステムに移行しようというときに、「店舗ごとにデータベースを入れたい」という話になりました。コンビニエンス ストアさんとかになりますと、各店舗のマネージャがデータを分析して、品揃えを決めたり、発注をしたりということがありましたので、それぞれの店舗にデータベースを置きたいということになりました。
そこで、数千以上にもなる店舗へ導入するデータベースは何にすべきかと考えたときに、選択肢としてはいろいろあったのですが、価格も決め手となって SQL Server を採用することになりました。実際使ってみると、正直 SQL Server 4.x の時代にはトラブルが多かったのですが、SQL Server 6.5 からはなんとか安定稼動するようになって、ダウンする確率が低くなりました。ここからスーパー マーケット系でも使えるようになりましたね。また、SQL Server 7.0 からは、本部系でもようやく使えるようになったという形です。

ページのトップへページのトップへ
*
**
SQL Server を採用し続ける理由
− 日本語処理のノウハウを非常に持っている会社であること
− ISV 向けのサポートが非常に充実していること
− メンテナンス フリーであり続けること
*
―――   皆さんは、SQL Server 4.x または 6.x 以降、SQL Server を使い続けておられますが、ズバリその理由は何でしょうか。

星野氏   私がデータベースを選択するうえで 1 番重要視しているのは、日本語処理の問題です。最近は少なくなってきましたが、昔はせっかくデータを入力したとしても、文字化けしてデータを取り出せなくなってしまうということがよくありました。

玉木氏   ごくごく最近までそうでしたよね。データベース自体が対応していたとしても、ドライバが対応していなくてそういう問題が起こったり。

星野氏   ええ、どこかがダメで結果が返ってこないということがありました。そういう意味では、SQL Server を含めた Windows プラットフォームは、日本語処理の部分で非常に安心感があります。あまり言われていないのですが、マイクロソフトは日本語処理のノウハウを非常に持っている会社の 1 つだと思っています。10 年以上も前から日本語をハンドリングしている会社ですから、たいへんな信頼感があります。
Linux 上で動作するデータベースは、その辺はどうなのかなと考えたときに、対応できる技術者は多分いないと思うんですよ。Linux を採用したとして、「日本語入力は本当にできるのか」とか、「文字化けせずにきちんと印刷できるのか」といったような点がものすごく気になります。そういったところがデータベースを選択する際の 1 番重要な要素の 1 つではないでしょうか。たとえ世界中で売れていても、日本でそれを採用するかどうかには、まったく違うポイントがあります。そういう問題はあまりメディアには出てこないので、企業としては心配になります。

黒川氏   私が SQL Server を採用し続けている理由は 2 つあります。1 つは、マイクロソフトの ISV 向けのサポートが非常に充実している点です。聞きたいときに聞ける窓口がある、これは何にも勝る安心感です。もう 1 つは、扱いが非常にイージーな点です。このサイトの MVP インタビュー (小川氏) の記事の中で「リッチなイージー」という表現がありましたが、まさにそのとおりだと思います。

玉木氏   私どもは、完成されたパッケージを販売するという形ではありませんので、SQL Server に限らずお客様の希望によっていろいろなデータベースをまんべんなく使ってきました。ただ、お客様がデータベースを細かく指定してくるというケースは少なく、「安定して動けばいい」という要望だったりします。そうなると、安定稼動かつメンテナンスがしやすいということで、3、4 年前からは Windows と SQL Server を積極的に提案してきました。
お客様の訪問先では、エンジニアが辞めてしまって、扱える人がいなくなって困っている UNIX 系のシステムがあったりします。バックアップさえもできずに個人的に相談されたりするのですが、そういった場面に遭遇するたびに Windows と SQL Server を勧める思いが強くなりました。

*黒川氏
*
黒川氏   サポートをビジネスにされている方にとっては、システムは複雑な方がいいかもしれませんが、パッケージにとってはデータベースはあくまでも裏に隠れていてほしいものです。我々の業務ソフトを利用されるお客様は、技術者だけではありません。PCA 会計を使う方が経理の事務社員であったり、また、PCA Dream21 (ERP) を使用されるのは企業の社長だったりします。
コンピュータを使い慣れた IT エンジニアだけが使うわけではありませんので、パッケージの裏で動くデータベースも、できる限り手間のかからないものの方が良いのです。そういった意味では、SQL Server は今のところほとんど初期設定のままで入っていますし、導入後もほぼメンテナンス フリーです。仮に何かあったとしても、GUI ツールがしっかりしていますので、まったくわからないお客様でも、電話で指示を出してトレースしてもらうことができます。他のデータベースだとこう簡単にはいきません。

―――   確かに Oracle だと電話でトレースをとるための指示を出すのは困難ですね。

三部氏   私が SQL Server を使い続けている決定的な理由は、個人的にはもう使い慣れていて、酸いも甘いもかみ分けていると言いますか、どこをどうチューニングすればパフォーマンスを改善できるかというのがだいたいわかっているところにあります。初期のバージョンのころからのノウハウが蓄積されてきて、もちろんバージョンが変わるごとに多少の性格の違いはあるのですが、使い慣れたというのが 1 番ですね。

ページのトップへページのトップへ
*
**
SQL Server の GUI ツールは大きな魅力の 1 つ
*
―――   SQL Server の GUI ツールというのは、やはり大きな魅力の 1 つでしょうか。

星野氏   最初のとっかかりとしては重要ですよね。Windows のインターフェイスなので、かなり簡単に操作できて、クリックしていくだけで実際のデータまで見ることができますから。

三部氏   SQL Server 6.5 からは、安定稼動すると共に、ユーザー インターフェイスが格段に良くなりましたね。当時、他のシステムを担当している同僚から「何故 Oracle を使わないんだ」と言われたことがありますが、「だって SQL Server はこんなに簡単なんだ」と見せると、「ああ本当だね」と容易に納得させることができました。

黒川氏   私は GUI ツールがなければ触っていなかったと思います。他社のデータベースも GUI ツールを出されていますが、どうも作り慣れていないというか、使いづらいんですよね。

星野氏   他社のデータベースは、そういうことを考えて作っていないのだと思います。データベースですからね。表に出てくるものではないので、そこは技術者が触ればよいだろうと考えている会社が多いと思います。

玉木氏   Oracle も 8i からは Java ベースのインストーラと管理ツールが付きましたが、何と中途半端なものを付けたのだろうという印象でした。これが Windows ベースだったら少しは違ったのかもしれませんが、それでもう抵抗ができてしまって「それならコマンドでやる」と思ったものです。結局、Oracle を使うときには、サード パーティ製の GUI ツールを使われる方がほとんどですね。

黒川氏   そう考えると、マイクロソフトは日本語の問題といい、GUI ツールといい、日本固有のニーズをよく吸い上げていると思います。

ページのトップへページのトップへ
*
**
SQL Server を採用し続けるのは MSDE の存在も非常に大きい
*
―――   SQL Server と互換性のある無償のデータベース エンジン「MSDE」* についてはいかがでしょうか。
―――   * : MSDE は SQL Server 2005 からは Express Edition が後継となります。

黒川氏   SQL Server を採用し続けるのは、MSDE の存在も非常に大きいですね。パッケージのスタンドアロン版には MSDE を使ってもらい、ネットワーク版にアップグレードしたときに SQL Server を使ってもらうことになるわけですが、ほとんど同じ操作性で使えるのが嬉しいですね。MSDE がなければ、Btrieve をそのまま使い続けて SQL Server を採用していなかったかもしれません。しかし、もし Btrieve を採用していたとしたら、今これだけのデータ量はさばけなかったと思います。

三部氏   MSDE の存在は大きいですね。我々のシステムでは、POS レジに SQL Server または MSDE が入っています。各店舗のストア サーバーと本部のサーバーには SQL Server が入っています。本部にあるデータベースの構造 (テーブル レイアウト) と、店舗サーバーにあるデータベース構造、POS レジのデータベース構造を同一にして、店舗コードやレジ No. を含めた形でキーを構成することにより (本来は POS レジには店舗コードは不要なのですが) 上から下まで一気通貫で構築できる。そうなるとどこへでも簡単にデータの移動やシフトができる SQL Server は本当に助かりますね。SQL Server も MSDE もストアド プロシージャも含めてデータベースは完全互換がありますから。

ページのトップへページのトップへ
*
**
お客様が Oracle を希望した場合はどうしているのか
*
―――   お客様の会社が既に Oracle を導入済みで、「ぜひ Oracle でやってほしい」と希望されたケースはありましたか。

黒川氏   ありましたね。パッケージの場合は、データベースはあくまでもエンジンとして動いていますので、滅多にあることではないのですが、大手メーカーさんの子会社で、親会社からデータベースの技術者の方がやってきて「うちは Oracle じゃないと技術者がいないから」と言われたことがあります。でも「エンジンに対して特別な技術者はいりません」と対応しました。
実は、PCA 会計は Oracle 版を出していたこともあるのですが、Oracle 版だと 1 件 1 件のサポートに手間がかかって仕方がありませんでした。データ量が増えてくると、チューニングが必要になってきますが、Oracle だとなかなか思ったように動いてくれません。その点 SQL Server であれば自動チューニングができるので、ほとんど何も考えずに使えます。もちろん 100 パーセント完璧とまでは言いませんが、自動チューニングがそこそこ効いて、メンテナンス フリーであり続ける SQL Server というのは非常にありがたい。今は、PCA 会計の Oracle 版が動いているところをどうやって SQL Server 版にリプレースしていこうかと考えています。そういう意味では、PCA という会社の中では Oracle の影は薄らいできています。

玉木氏   Oracle を希望されるお客様の場合、必ずしも明確な理由があるわけではないケースも多いですね。Visual Basic や Access、Excel をクライアントとして使うのになぜ Oracle を使うんだろうと思ったこともあります。Oracle では、Excel を使うためにわざわざ KeySQL を購入したりするケースもあります。

―――   確かに Oracle 社の発した宣伝をそのまま受け取って、雰囲気だけで Oracle を選択されるという方もいらっしゃいますね。そういう方には、ぜひ 1 度 SQL Server を試してほしいと思います。

星野氏   当社では、お客様から Oracle の要望が出たことはないのですが、OS との親和性を考えるとやはり SQL Server をお勧めしますね。Oracle は、ミニコンでも、ワークステーションでも動いて、さらに PC のネットワークでも動くというマルチ プラットフォーム製品であるがゆえに「本当に速いの？」と疑いたくなります。OS が変わってもきちんとチューニングできているのか、という疑問が残り、それは今も引きずっていると思っています。

玉木氏   なんだかんだで Oralce が 1 番稼動している OS は Windows が 1 番多いというのもあったりして、そういうところでも矛盾が起こっていますよね。

黒川氏   少し外れるかもしれませんが、マイクロソフトは OS のロードマップが明確にあるじゃないですか。それに対して SQL Server もきちんとロードマップに対応した製品が互換性を保ちながら出てくるという安心感があります。
Oracle の場合は、Windows をバージョン アップすると互換性の部分があまり良くなかったりします。我々のお客様は、100 人使っていれば 100 人が Windows を使っていますので、OS のバージョン アップにきちんと互換性がないと、提供する側の恐怖心があります。

ページのトップへページのトップへ
*
**
Oracle の場合はサポートやコンサルティングの価格も考える必要がある
*
三部氏   私どもは、お客様が Oracle を希望した場合は Oracle ですね。ただ、自分で選べる場合は、価格の面から SQL Server を選択します。これは単なるソフトウェアの価格だけではなくて、サポートやコンサルティングまでを含めた全体の価格になります。Oracle だとそういった諸々の費用が本当に高いですから。

―――   Oracle はソフトウェア (データベース) のライセンス料金だけでも本当に高いですね。特に Enterprise Edition で規模が大きくなると桁違いの金額差になりますし、SQL Server では標準搭載されるような機能がオプションとして別途費用がかかったりするのは大きな差ですね。

黒川氏   最近は、Oracle は高くないという宣伝を見ることがあります。Linux なら OS が無償だからということらしいのですが、実は Linux 上で Oracle というのは、それをサポートするために高額な対価を支払わないとサポートしてくれるところがなかったりします。そう考えると実は安くなくて、逆に高くつくのではと思ってしまいます。

三部氏   Oracle は、データベースのチューニング ツールでも、Quest Software や VERITAS Software (現 Symantec) などが販売していますが、Oracle 版は SQL Server 版に比べて 1 桁高かったりします。その分機能も豊富ですが、Oracle だから許される特別な価格レンジというのがあるようです。

ページのトップへページのトップへ
*
**
オープン ソースのデータベースを選定する余地はあるか
*
―――   オープン ソースのデータベース (PostgreSQL や MySQL) の導入を検討されたことはありますか。

*玉木氏
*
玉木氏   低コストでどうしても何とかしなければならないという案件では、PostgreSQL や MySQL を使うこともあります。ただ、いくら初期コストが安く抑えられても、導入後の運用や拡張性までを含めた全体でコストが安いかと言うとそうではありません。急にエンタープライズ的な要素を求められて、たとえばクラスタを導入したいなどと言われると、サード パーティの製品を買わなければならず、結果として高く付いたりします。それなら最初から SQL Server を使おうということになるわけです。
また、最近の新聞記事の話になりますが、ある小学校で Linux ベースの PC を導入していたのを全部 Windows に入れ替えたそうです。読み進めていくと、結局メンテナンスやソフトのアップデートに時間がかかるのと、最後には「Linux に詳しい担当者が異動になったため」という経緯が書いてありました。だいたい Linux が入っているところは、Linux に詳しいエンジニアがいたりします。しかし、そのエンジニアがいなくなったときのことも考えて導入する必要がありますね。

黒川氏   それはまさに当社の状況にも当てはまっています。社内に Linux 上で動作する、とあるシステムがあるのですが、それが PostgreSQL を使っています。当時、在籍していた技術者が無償だからということで作ったシステムなのですが、その技術者がいたときは良かったんですが、退職してしまった途端にそのシステムはバージョンが固定です。もうハードウェアが壊れないのを祈るばかりです。

―――   なるほど。オープン ソースの採用にあたっては、導入時だけでなく、その後の障害対応やバージョン アップといった運用管理までを含めて考慮する必要があるというわけですね。

玉木氏   あと、オープン ソースで 1 番たいへんなのは、いろいろな場所からデータを集めてくるプログラムを書かなければいけない点ですね。SQL Server であれば、DTS (データ変換サービス) が標準で付いているので、わざわざそういったプログラムを書かなくてもデータが集められます。オープン ソースを使っていると「DTS を使わせてくれ」という場面がよくあるため、DTS は本当に便利だと感じます。
DTS は、SQL Server 2005 からは Integration Services に名称が変わって、さらに良くなっているのですが、これだけでも SQL Server を買う価値が十分にあります。

ページのトップへページのトップへ
*
**
Access ユーザーへのアドバイス
− Visual Studio 2005 は Access と同じような感覚で SQL Server を利用できる
*
―――   日本では Access から SQL Server への移行を検討されているユーザーがたくさんいらっしゃると思いますが、何かアドバイスはありますか。

星野氏   日本では、MS-DOS から Windows に切り替わった時代のデータベース ソフトというと Access くらいしかありませんでした。1995 年ごろからの数年間で SQL Server に移行しないで Access をそのまま使い続けているというケースは本当に多いですね。しかし、ネットワークを介して Access を使用する場合、利用者が増えるとすぐにパンクしてしまいます。すべてのデータを持ってきてしまうので、これは厳しいですね。
また、今までは Access ユーザーにとって SQL Server は敷居が高く感じるところがあったかもしれませんが、Visual Studio 2005 からは大きく変わっています。Visual Studio 2005 を使えば、Access と同じような感覚で簡単に開発できます。SQL Server のデータベースをコピー & ペーストし、Access と同じようにローカル ファイルのように取り込んでテストすることができます。テスト環境のイメージは Access とほとんど同じですね。これがあれば、移行はそれほど難しくないと思います。

ページのトップへページのトップへ
*
**
SQL Server 2005 に期待すること
*
―――   ついに SQL Server 2005 が完成しましたが、どういったところに期待していますか。

黒川氏   業務ソフトとして心待ちにしているのは「データベース ミラーリング」機能です。これは本当にすごくいい。特にインターネットを介して物理的に離れた拠点でミラーリングを行いたいというニーズは非常に高いです。

玉木氏   ディザスタ リカバリ (Disaster Recovery: 災害復旧) 用途ですね。

黒川氏   日本では地震の問題はやはり考慮しなければなりません。噂では、沖縄のデータ センターが人気があるらしいですね。そう考えると、データというのはすごく大切だと思われているということですね。

三部氏   今は回線が太くなってきて、大量のデータを流しても問題がなくなってきているのも大きいですね。

玉木氏   私が SQL Server 2005 で期待しているのは「64 ビット版」ですね。私は比較的大規模なデータをハンドリングすることが多いので、SQL Server 2000 でも途中から 64 ビット版は出ましたが、それまではずっと不自由をしていて、物理的にないということを言われて肩身の狭い思いをしてきました。非常に悔しい思いをしてきましたが、ようやく最近の大規模な案件では 64 ビット版を活用しています。
それから「Reporting Services」の存在も大きいですね。我々は、カードのポイントが何ポイント貯まったとか、そういった Web ベースのグラフを作成することが多くあります。今まではサード パーティ製のコンポーネントを買ったりする必要があったのが、Reporting Services があれば、ドラッグ & ドロップで簡単にレポートが作れたりします。システムに応じて臨機応変の対応が求められる会社にとっては、非常に便利な機能です。

―――   Reporting Services は、SQL Server のすべてのエディションに標準機能として同梱されているのもありがたいですね。

*三部氏
*
三部氏   私はやはり「SQLCLR (SQL Server 2005 に統合された、.NET 共通言語ランタイム)」ですね。私自身ここ 5 年ずっと .NET をやってきましたので、ようやく期待に沿うものが登場したという感じがします。パフォーマンスを考慮すると、ストアド プロシージャに頼ることが多いのですが、単にクエリを発行し、UPDATE して、INSERT するだけではなく、その中でかけ算や引き算、割り算をしたりとデータの操作が発生します。そうすると、ときどきパフォーマンスに問題が出たりするのですが、SQL Server 2000 では解決策がありませんでした。
それが SQL Server 2005 で SQLCLR が登場したことで、C# でストアド プロシージャが書けるようになります。もちろん、処理の内容によってパフォーマンスが速いものと遅いものがあるのですが、速いものであれば、50 倍から 70 倍ぐらいに速く演算できるという検証結果も出ています。今あるシステム全部を置き換えるとなるとたいへんですが、要所要所で困っているところを置き換えていける、そういった解決策が出てきたというのが非常にうれしいですね。たいへん助かります。
今まではストアド プロシージャで駄目ならもう駄目というところがあったのが、まだ改善できる余地があるというのは大きいですね。

黒川氏   パッケージを全部 SQLCLR に置き換えるとなると、作り直しになってしまいますが、パッケージにアドオンするプログラムとか、それと連結するプログラムを書くときには、確かに SQLCLR は便利ですね。
あと、私個人としては「ADO.NET 2.0」が非常に気に入っています。ADO.NET は非接続型のアクセスがよく取り沙汰されるのですが、実は業務パッケージには非接続型というのは非常に使いづらいところがあります。今回お話させていただいたように、我々の業務ソフトを利用されるお客様は、社長や経理の事務社員といったコンピュータを使い慣れていないユーザーです。そのためセットアップ 1 つにしても、昔はお客様に「setup」という 5 文字を打たせるのではなく、「p」という 1 文字だけにして手間をなくすという努力をしてきました。
しかし非接続型では、登録ボタンを押してコミットしたときに、裏で誰かに書き換えられてますよというメッセージが表示されたりします。これでは、ユーザーにひどく怒られてしまいます。書き換えられているのなら、最初から入れた瞬間に通知しておけというのが理由です。入れられるから入れたのに、登録段階でこれは裏で更新されているというのは「冗談を言うな」と。そういう世界で私は仕事をしていますので、ある程度接続型のアクセスをしなければなりません。ところが従来の ADO.NET のデータ セットというのは、接続型で使うには非常に使いづらいところがありました。それが ADO.NET 2.0 になって、たいへん使いやすくなりました。こういった理由から、ADO.NET 2.0 は個人的にマイブームです。私と同じような業務アプリケーションを書かれる方には非常にお勧めの機能です。

三部氏   あと SQL Server 2005 には、「リアルタイムなデータ分析」と「XML」機能に期待しています。最近の POS システムは、各店舗にサーバーを置かない集中センター サーバー系にだんだん変わってきています。POS システムでは、レシート 1 枚に対してトランザクションが発生しますが、トランザクションがリアルタイムでセンター サーバーに反映されるようになって、それをリアルタイムで分析できるようになることが求められてきています。また、リアルタイムに多事象分析をしつつ、その裏で動く発注系のシステムとリアルに連携できるだけのパフォーマンスが出ることも SQL Server に期待したいところになります。
もう 1 つは XML で、これはもしかしたら SQL Server 2005 ではなく、その次のバージョンに期待することなのかもしれません。今後 RFID がすべてのものに付くようになったときに、そのマスタ データは全部が同じテーブル構造かというとそうではないと思います。ただ、問い合わせてくるユーザーは、その RFID に入っているキーだけで問い合わせるので、その構造に対しても情報が必要になります。しかしさまざまなテーブルがあるので、それを全部 XML のデータとしてデータベースの中に格納するようにして、かつインデックスを付与してすばやく取り出せるようになるという需要が、今後あと 1、2 年で必ず高まると思っています。米国では、やはりそういうのをいろいろな研究者が既に研究していて、すごく速い XML 専用のデータベースが存在しているのですが、それらはコストが非常にいい値付けになっています。そこで、それらに匹敵するだけの XML のサーチ パフォーマンスを備えた SQL Server が登場し、かついつもの価格で提供されるということを期待しています。

黒川氏   これは実は、ちょうど私どもの基幹系にもあります。最近 POS レジ系の案件が多いのですが、基幹業務の構造はわりと複雑でして、1 つの伝票から残高の問題や、在庫の問題とか、ERP 系では振替伝票の問題もあったり、かなり重い処理をすることになるのですが、そのときにリアルタイムでデータ分析をしたいということを必ず言われます。このとき、前裁きとしてどれだけ速いパフォーマンスが出るかというのがポイントになりますね。
また、異なった構造のテーブルを簡単に扱える製品というのを望まれる方も非常に多いですね。当然、基幹業務に流れてくるのは決まった POS レジの形式だけではなく、経費精算の振替伝票であったり、営業日報などに経費が埋め込まれたような形であったりもするわけです。そういったものを高速に前で裁いておいて、裏で重い処理 (ERP の基幹業務へのストア処理、裏でサマリされた結果) ができる、つまり請求書や決算書が作れます。お客様としてはそれらが取得できれば良いわけですから、そういったところが今後のポイントになってくると思います。

―――   皆様、本日はどうもありがとうございました。SQL Server を古くから導入され、現在も使い続けていらっしゃる皆様からたいへん貴重なお話を伺うことができました。これから SQL Server の導入を考えていらっしゃる方々にとって、大いに参考になったのではないかと思います。長い時間、本当にありがとうございました。

ページのトップへページのトップへ
*
READY STATION のトップへREADY STATION のトップへ
*
Back Number
*
**
**