C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[1]: ADO.netの接続形態別の速度の違いについて

分類:[.NET 全般]　

　お世話になっております。

旧ADOの時代は、OLEDBProviderとODBC経由では速度に明らかに違いがありました。
Oracle(8iの時代に)で比較実験をしたことがあるのですが、

当時、VBからOracleにつなぐのに最速といわれていたoo4oとADOのOLEDBProviderのスピードの差は
Recordsetのループレベルだとほとんどなく、
OLEDBProviderとODBC経由の差の方が目に見えてありました。

その当時のOLEDBProviderとODBC経由の差はオブジェクト階層が一階層多いからと説明されていた文書並びにサイトが
多かったように記憶しています。

ADO.netでの場合、そのあたりの違いは、どの程度なのでしょうか？
ADO.netではOLEDBProviderも下位互換となり、
上記の基準からすると、
.Netproviderよりも1階層多くなるので
ODBC経由同等に遅いように思いますが、
OLEDBProvider経由とODBC経由の差はあるのでしょうか？

今担当しているシステムでは、
ADO.netですが.Netproviderではなく、

SQLServerはOLEDBProvider経由、
某F社製SymfowareはODBC経由で接続してます。

理由は、.Netに変換する前がVB6でADO or RDOで接続していたため、
そのままの接続形態でADO.netに移行したためと思われます。

質問の意図は、数年に1度ある全面刷新時に、
.Netprovider接続への移行を実施するかの判断材料の一つとしたいです。

よろしお願いします。

■No83130 (大谷刑部さん) に返信

.NET アプリから ADO.NET を使って SQL Server に接続するならプロバイダは SqlClient
一択ではないのでしょうか。

.NET Framework データプロバイダー
https://msdn.microsoft.com/ja-jp/library/a6cd7c08(v=vs.110).aspx

ただ、

> 数年に1度ある全面刷新時に、.Netprovider接続への移行を実施するかの判断材料

とするために、具体的にどのくらい高速になるかを示せと言われると、自分はそれに対す
る答えは出せませんが。

2017/03/07(Tue) 17:19:08 編集(投稿者)

■No83130 (大谷刑部さん) に返信
> 旧ADOの時代は、OLEDBProviderとODBC経由では速度に明らかに違いがありました。

Update が若干早いものの MoveNext がヤケに遅いとか、何か違いがあった気がしますが
今となってはすっかり忘却の彼方です…。orz

> Oracle(8iの時代に)で比較実験をしたことがあるのですが、

MSDAORA
OraOLEDB.Oracle
ODBC(MSDASQL) + Microsoft Oracle Driver
ODBC(MSDASQL) + Oracle ODBC Driver
ODBC(MSDASQL) + Merant/DataDirect ODBC Driver

などなど、色々な組み合わせがありましたね。
サードパーティ製の ODBC Driver や OLE DB Provider もありましたし。

> その当時のOLEDBProviderとODBC経由の差はオブジェクト階層が一階層多いからと説明されていた文書並びにサイトが
> 多かったように記憶しています。

ミドルウェアの階層ですね。

DAO Workspace - Jet Engine - ODBC API - Net8 - Oracle
DAO(ODBCDirect) - ODBC API - Net8 - Oracle
RDO - ODBC API - Net8 - Oracle
ADODB - OLEDB(MSDASQL) - ODBC API - Net8 - Oracle
ADODB - OLEDB(MSDAORA) - Net8 - Oracle
ADODB - OLEDB(OraOLEDB.Oracle) - Net8 - Oracle
OO4O - Net8 - Oracle

# http://pcdn.int21.co.jp/pcdn/vb/howto/oracle.html
# http://www.int21.co.jp/directmw/DirectMw.html

Jet の ODBC リンクテーブルだと、スキーマ情報がローカルキャッシュされるので
ADODB よりもむしろ高速になるケースもあったと記憶しています。といっても、カーソル処理が
ローカル側で行われる分、処理によっては逆に低速にもなりえるのですが。

> ADO.netでの場合、そのあたりの違いは、どの程度なのでしょうか？

対 Oracle 向けの ADO.NET 実装というと、主要なところでは
下記の組み合わせが思い当たります。

1～4 については、OLE DB Provider 層や ODBC 層を経由することに
なってしまいますので、現行バージョンなら 6 か 7 を使うのがお奨めです。
特に OLE DB 層は、今後縮小傾向にあるようですし。

0) Microsoft.Data.Odbc + Oracle ODBC Driver/Microsoft Oracle Driver
1) System.Data.Odbc + Oracle ODBC Driver
2) System.Data.Odbc + Microsoft Oracle Driver
3) System.Data.OleDb + MSDAORA
4) System.Data.OleDb + OraOLEDB.Oracle
5) System.Data.OracleClient
6) Oracle.DataAccess.Client
7) Oracle.ManagedDataAccess

7 は XCOPY 配置で動作するので、実行環境への配置が容易ですが、
12c で登場したばかりで歴史が浅いです。

機能面で比較すると 6 の方が優れていますが、バージョン互換性に問題があるため、
複数人での開発(特に複数の Oracle バージョンを扱う開発チーム)では注意が必要です。
http://d.hatena.ne.jp/atsukanrock/20090519/1242721158

5 については、Oracle Client 8.1.7 以降さえあれば使えるので配置は容易ですが、
.NET 4 以降では廃止(Obsolete)扱いにもなっており、現在は非推奨な方式となっています。

3 はそもそも、Oracle 8i までのサポートしかありません(9i 以降に繋げないわけでは無いですが)。

> SQLServerはOLEDBProvider経由、

対 SQL Server への接続案なら、.NET からは基本的に
System.Data.SqlClient 一択です。(Compact なら System.Data.SqlServerCe)

しかし ActiveX 系での接続については、もはや OLE DB Provider は
推奨されていません。SQL Server 2012 を最後に OLE DB Provider が
提供されなくなり、現行バージョンでは ODBC が推奨されるという
逆転現象が発生しています。

https://blogs.msdn.microsoft.com/sqlnativeclient/2011/08/29/microsoft
https://blogs.msdn.microsoft.com/dataplatjp/2016/06/16/sql-server

■No83132 (魔界の仮面弁士) に追記
>>Oracle(8iの時代に)で比較実験をしたことがあるのですが、
> などなど、色々な組み合わせがありましたね。

CLR1 + 10gR1 世代の古い資料(もはや古文書)ですが、
下記の 17 ページ目や 20 ページ目に、ODP.NET の優位性が説かれていました。
http://otndnld.oracle.co.jp/tech/windows/odpnet/pdf/odd_odpnet.pdf

》- ODP.NETは.NET専用のネイティヴ・ドライバーである
》　・ ODBCに比較して4～5倍のパフォーマンスが出る

現状だと、64bit 版が登場したり、ODP.NET にも Managed 版(管理対象ドライバ)が登場したりと
幾許か変化はありますが、現状で ODBC 接続を選択するメリットは無いと思います。

ODBC 接続しか用意されていないデータベースが相手ならいざ知らず、
対 Oracle なら ODP.NET Unmanaged Driver もしくは ODP.NET Managed Driver、
対 SQL Server なら System.Data.SqlClient ぐらいしか選択肢が無く、
優位性のある代替接続手段は、今のところ思い当たりません。

他のデータベースに移行するための互換性確保が目的なら、
上記を System.Data.Common 経由で使えば対処できますしね。

# 対 *.accdb の場合は、ACEDAO でしか呼べない機能もあるので微妙なところですが。

■No83133 (魔界の仮面弁士さん) に返信
> ■No83132 (魔界の仮面弁士) に追記

> ODBC 接続しか用意されていないデータベースが相手ならいざ知らず、
> 対 Oracle なら ODP.NET Unmanaged Driver もしくは ODP.NET Managed Driver、
> 対 SQL Server なら System.Data.SqlClient ぐらいしか選択肢が無く、
> 優位性のある代替接続手段は、今のところ思い当たりません。

色々とありがとうございます。
その通りだと思います。
OLEDBがODBCよりむしろ遅いケースありというのは寝耳に水でしたが、
逆にその情報があれば、.NetProvider接続に替える動機として、
プロマネクラスを説得する有力な材料になります。

> 他のデータベースに移行するための互換性確保が目的なら、
> 上記を System.Data.Common 経由で使えば対処できますしね。

その通りと思います。
むしろそうした方が、コードの修正工数が減る
(というより接続文字列をiniファイル等に外出しすればなし?)
ことになるので、ADO.net用の共通関数クラスに
System.Data.Commonのパターンを追加すれば済むと思います。
現状はなぜかコネクションオブジェクトをSystem.Data.Common
受け皿で汎用的型として宣言しておいて、
Newで接続文字列を読み取って
コネクションオブジェクトオブジェクトNewしなおすという特殊なことをしてます。

F社のSymfowareがODBC経由である理由は、
Symfowareの.Netproviderが.Net 1.Xの時代にはなく、ノウハウがVB6→.Netの時期に少なかったことと
接続文字列の指定の仕方がOracleやSQLServerと違って汎用的な切り替えロジックにしにくいなど
ODBC経由の方が汎用的かつ環境構築が簡易という事情が判断基準にあったようです。
尚、元請がF社なので、
SymfowareをやめてOracleやSQLServerという選択肢は今のところ考えづらいです。

■No83135 (大谷刑部さん) に返信
>>他のデータベースに移行するための互換性確保が目的なら、
>>上記を System.Data.Common 経由で使えば対処できますしね。
> むしろそうした方が、コードの修正工数が減る
> (というより接続文字列をiniファイル等に外出しすればなし?)

独自管理にすることもできますが、app.config にもエントリが用意されています。
どの ADO.NET プロバイダを使うのか。その場合の接続文字列を何にするのか。
https://msdn.microsoft.com/ja-jp/library/dd0w4a2z%28v=vs.110%29.aspx

> 現状はなぜかコネクションオブジェクトをSystem.Data.Common
> 受け皿で汎用的型として宣言しておいて、
> Newで接続文字列を読み取って
> コネクションオブジェクトオブジェクトNewしなおすという特殊なことをしてます。

.NET 1.x 世代の System.Data.IDbConnection を踏襲した実装なのかも知れませんね。
.NET 2.0 以降の System.Data.Common を使うなら、GetFactory からの CreateConnection で
Connection を張ったほうが汎用的かと思います。

> F社のSymfowareがODBC経由である理由は、
現行バージョンがどうなのかは知らないのですが、
古いバージョンは、"Symfoware ODOS" による ODBC 向け型付DataSet を
ブリッジコードとして、Symfoware 用の SNDP コードを作成する仕様だったようです。
（Symfoware 向けの開発を直接担当したことが無いため、詳しいことは知らないです）

Symfoware V12 .NET Data Provider
　http://software.fujitsu.com/jp/manual/manualfiles/m140025/j2ul1738/08z200/index.html
　　"Fujitsu Npgsql .NET Data Provider"
　　Npgsql 名前空間
　　型付 DataSet 生成には、Npgsql Development Tools for .NET を利用

Symfoware V11 .NET Data Provider
Symfoware V10 .NET Data Provider
　http://software.fujitsu.com/jp/manual/manualfiles/m120020/j2ul1605/03z200/index.html
　http://software.fujitsu.com/jp/manual/manualfiles/M100005/J2X17486/01Z200/index.html
　　"Symfoware .NET Data Provider"
　　Fujitsu.Symfoware.Client 名前空間
　　型付 DataSet 生成には、SDT.NET (Symfoware Development Tools for .NET) を利用
　　一部機能は、System.Data.Odbc 標準のコードジェネレーターで生成したものを
　　ブリッジコードとして、ファイル単位で SNDPコードを生成する方式

> 尚、元請がF社なので、
技術面の疑問なら、F 社に相談するわけには行かないのでしょうか。

■No83136 (魔界の仮面弁士さん) に返信
> ■No83135 (大谷刑部さん) に返信
> >>他のデータベースに移行するための互換性確保が目的なら、
> >>上記を System.Data.Common 経由で使えば対処できますしね。
>>むしろそうした方が、コードの修正工数が減る
>>(というより接続文字列をiniファイル等に外出しすればなし?)
>
> 独自管理にすることもできますが、app.config にもエントリが用意されています。
> どの ADO.NET プロバイダを使うのか。その場合の接続文字列を何にするのか。
> https://msdn.microsoft.com/ja-jp/library/dd0w4a2z%28v=vs.110%29.aspx

これは、iniファイル読込によく使うWinAPIが全面廃止されない限り、
変える予定は今のところありません。
理由は読込ロジックというより、ファイルの中身の問題で、
単純にiniファイルの方が読みやすいというだけです。

接続文字列に限定すれば、階層をつける必要もないので、
XMLにするメリットがあまりないということです。
iniファイルはただのテキストファイルなので、
.Netの知識がほとんどない人でもたぶん読めるので、
場合によっては、エンドの情シス担当切り替え対応が可能になります。
XMLだと拒否反応を示す人が技術屋以外では以外と多いです。

>>現状はなぜかコネクションオブジェクトをSystem.Data.Common
>>受け皿で汎用的型として宣言しておいて、
>>Newで接続文字列を読み取って
>>コネクションオブジェクトオブジェクトNewしなおすという特殊なことをしてます。
>
> .NET 1.x 世代の System.Data.IDbConnection を踏襲した実装なのかも知れませんね。
> .NET 2.0 以降の System.Data.Common を使うなら、GetFactory からの CreateConnection で
> Connection を張ったほうが汎用的かと思います。

System.Data.Common.DbConnectionで宣言しているので、
本来はそれをそのまま使えばいいだけと思います。
クラスのNewメソッドでわざわざNothingにして
Openメソッドでそれぞれのクラスの型にNewしなおしています。
汎用性の観点からは全く無駄なことをしている共通関数クラスです。
また接続文字列が読み取れないときのデフォルトがOLEDBになっているので、
VB6のマイグレ、下位互換を徹底的に優先したとしか思えないロジックになってます。

>>尚、元請がF社なので、
> 技術面の疑問なら、F 社に相談するわけには行かないのでしょうか。
それは多分できます。
また、手元にSymfowareのマニュアルもあるので、
概ねできることの内容は把握してます。
マニュアルの内容から想像できるのは、

(1).Netprovider自体が2.x系と4.x系に分かれていて、.NetFrameworkのバージョンをあげると同時に
　.Netproviderの検証も必要になる。

(2)インストールしただけだと使えない。
なぜか登録用(.Netベースでなぜレジストリ登録が必要?)のツールを動かないと使えない。
　この点、SQLServerやOracleより不便。

(3)ネットで検索するとSymfowareに関しては、ほとんどODBC経由のサンプルが出てくる。

(4)なぜかポート番号の指定が必要だったり、プロバイダーの指定箇所が無かったり、
　この点もSQLServerやOracleとやり方が違う。

などODBC経由をやめるの躊躇させる材料が結構あります。
過去の担当者はおそらくそれでODBC経由のままにしたと想定されます。

私の中でも、SQLServerよりは優先度が低いと考えています。

>>尚、元請がF社なので、
の部分は政治的意味です。
たまに、リンクしていただいた記事の著者であるF氏のように、
Fグループ製品にこだわらない方も存在しますが、
私が関わったFグループの方の大半はFグループ製品にこだわります。
なので、動いているFグループ製品を変えるという選択肢を取る人はほとんどいません。
過去には、F社はあるパッケージの帳票をCrystal Reportから全部List Creatorに変えたこともあります。
現場の協力会社には大不評だったそうです。

なので、可能性の話として、
Symfowareをやめるというよりは、
Symfowareを使う前提で、最善の策を講じるというのが現実線です。

SQLServerを使っている箇所は初期会社がF社ではありません。
ある時期にF社が引き取っています。
なのでできるとすれば、SQLServerからSymfowareに変えるのを阻止することくらいです。

C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[1]: ADO.netの接続形態別の速度の違いについて

過去ログには書き込み不可