 |
||||||||||||||
|
||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||
|
||||||||||||||
| SQLは今や昔？ | ||||||||||||||
|
「データベース移行」の際の強い味方であるSQLですが、最近ではSQLをアプリケーション側から直接的に操作するという従来の方法が、やや陳腐化してきている傾向が見受けられます。 「データベース移行」に対して強いSQLですが「スキーマ変更」に対して考えてみるとどうでしょう。開発や運用の段階で改良や仕様の変更が発生した場合、テーブルのスキーマが変更されるケースは少なくありません。 例えばカラムが1つ追加された場合に、該当するテーブルやカラムを操作すべき箇所のSQLを、ソースコードの広い範囲で書き換える必要があります。しかしSQLは単純な英文のような文字列で構成されているため、どこを書き換えるべきかを調べるためのマッチング作業にも非常に骨が折れます。条件によって"節"単位で動的にSQLを組み立てているプログラムの場合は目もあてられません。 そこで近年では、SQLを直接的に使用しないでデータベースを操作するO/Rマッピング（Object-Relational Mapping）という概念が浸透しつつあります。  図2：O/Rマッピングを利用した処理 従来のアプリケーションは、データベースに対してSQLを発行し、取得したカラムの情報をそのまま変数や配列に代入し「どの変数、どの添字の値がどのカラムの値であるか」ということを意識して開発するスタイルでしたが、この抽象化されたオブジェクトを経由することによって、そのような煩雑な思考を巡らせることなく、オブジェクトからカラム名のアクセサメソッド呼び出しを行ない、値の取得、更新を行なうということが可能になっています。 ただ、誤解のないように付け加えさせてもらえば「SQLという言語や概念がもう古い」ということではなく「SQLを直接的に使用することがもう古い」という表現が正しいのでしょう。O/Rマッピングを行なってくれるインターフェースの多くが、内部的にSQLを組み立てて実行し、返された値をオブジェクトに利用し易い形にマッピングするような設計であるだけであり、その裏でSQLは今もまだ第一線で活躍中なのです。 |
||||||||||||||
| O/RマッパーとWebアプリケーションフレームワークの傾向 | ||||||||||||||
|
O/Rマッピングを行なうインターフェース（ライブラリやフレームワーク）は、一般的にO/Rマッパーと呼ばれ、特にJavaでは盛んに利用されている傾向があります。各言語における代表的なO/Rマッパーを表2に示します。
表2：各言語の代表的なO/Rマッパー この傾向が強い理由については想像の域を超えないのですが、単純に開発する側にとっての選択肢として、O/Rマッパーを特定のものに制限してしまわないほうが良いという考えや、必ずしもデータベースがWebアプリケーションに関連づくわけではないという考えがあり、それぞれ独立して考えることによって柔軟性の向上や、選択肢の幅を広げられるというメリットがあるのではないでしょうか。 |
||||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
