データベースを抽象する利点と欠点について教えてください。
多くの言語において、抽象化は当然のように行われています。
しかし、個人的に思うのは、実態として、使用するデータベースを
意識しないことにはコーディングできません。
そのため、抽象化されたAPIはかえって邪魔に感じます。
門外漢ながら、ADO.NETはデータベース毎にAPIが存在しているようなので、
抽象化が良いと思わない私の考えの後押しとなっています。
ご意見お待ちしてます。
> しかし、個人的に思うのは、実態として、使用するデータベースを
> 意識しないことにはコーディングできません。
これはむしろ逆ではないでしょうか。APIを抽象化することにより、その先のデータベースの違いを意識することなくコーディングが行えるようになります(データベースの違いをAPIが吸収してくれるという意味です)。一度習得してしまえば、ほかのデータベースを利用したシステム開発も容易です。
利点:構成の変更などに柔軟に対応できる
欠点:オーバーヘッド
確かに、同感な部分もあります。
結局、主にパフォーマンスの観点から特定のDBMSの特性に合わせた
実装をせざるを得ないことが少なくないです。
それに、実際DBMSを切り替えるなんて言う根本的なインフラが覆る
ようなことをする事は、実際はほとんどないですし。
と、前置きしておいて私の思う利点・欠点ですが。。。
○利点
1.ユニットテスト可能
主にコレかなと思っています。DBMSを抽象化することで、
モック(擬似DBMS)と切り替えて、ユニットテストする
ことが可能になると思います。
2.1つAPIを覚えれば良い
APIが統一されていることで、そのAPIさえ覚えれば、基本的に
どのDBMSに対してでもプログラミングできます。
各DBMS毎にAPIが異なれば、それらを逐一覚えなければならず、
技術者確保も難しくなりそうです。
○欠点
1.APIの複雑化
APIに汎用性を持たせるため、複雑になりすぎるので
プログラミングが煩雑になりがちだと思います。
この点は、プロジェクトにあわせて各種フレームワークや
共通部品化で煩雑な部分を隠蔽すれば良いと思います。
概ね同感です。利点の1について、私の勉強不足により、
ピンと来ないところがありますが。
>実態として、使用するデータベースを意識しないことにはコーディングできません。
確かにそういう現状ではあります。しかし、完全ではないから抽象化は必要無いというのも飛躍しすぎではないかと。
DB製品ごとに個別対応が必要になりそうなのは、SQL方言やシーケンスなどでしょう。確かに現状の抽象化フレームワークはこれらを抽象化していないので不満を感じるかもしれませんが、これは敢えて抽象化していないのだと思います。
つまり
アプリ層←→抽象化フレームワーク
と考えるから不満が出るのです。
アプリ層←→高次抽象化層←→抽象化フレームワーク
と考えてはどうでしょうか。
【抽象化フレームワーク】
connect、クエリ実行、カーソル操作、プレースホルダーなどの低レベルの抽象化層と考える。
【高次抽象化層】
これはプログラマが自分で(都合の良いように)実装する。
例えばSQL方言やシーケンスの抽象化。
【アプリ層】
直接アクセスするのは高次抽象化層とする。
このレイヤでは、シーケンスなどの野蛮な概念は排除して、「ユニークキー取得」みたいな考え方をする。
では、最初から高次抽象化層も含めたAPIにすれば良いのでは?という議論もあるかもしれませんが、現実としては難しいでしょう。
特にOracle社は独自路線を改める気配がありませんし、今後はオブジェクト指向DBやXML-DBなどの新しいパラダイムが台頭する可能性もあり、少なくとも現時点で画一的な抽象化を策定するのは無謀です。
概ね同感です。勉強になります。
>データベースの違いをAPIが吸収してくれる
完全にそうであるなら結構なのですが、抽象化を実現するため、
APIの仕様があいまいになっていると感じます。
これはJavaのJDBCで感じたことですが、あるデータベースでは
あるメソッドが実装されているが、別のデータベースでは
実装されてないということがある。
このようなあいまいなAPIで大事なデータを扱うことには不安を
感じます。しかし、使わざるを得ないことが多いため、
実際のところどうなっているのか調べるコストが発生する。
だったら、最初から、APIの抽象化はない方がよいのではと思います。