| ■83135 / ) |
Re[3]: ADO.netの接続形態別の速度の違いについて |
□投稿者/ 大谷刑部 (16回)-(2017/03/07(Tue) 18:33:10)
|
■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という選択肢は今のところ考えづらいです。
|
|
