DB2でさくさく実現するRESTfulなDBアプリ(2)
Railsでレガシーデータを蘇えらせるテクニック
既存の表にActiveRecordを使うには?
前回は、DB2とRuby on Rails、そしてActiveScaffoldを使うための環境準備を行い、それらを使って簡単なテーブル保守アプリケーションを作成しました。
このとき、アプリケーションからアクセスする表そのもののデータベース側への作成は、モデルの作成時に生成されたスクリプトに対してmigrateを実行して行いました。
Railsのmigrateによる表管理は簡単ですが、既存の表(レガシー表)に対してActiveRecordを用いたいといった要望も考えられます。そこで今回は、Railsからレガシー表にアクセスする方法を紹介します。
ActiveRecordを使ったマッピング
ActiveRecordはデータベースからデータを読み出す際のアプローチの1つです。具体的にどのようなものか、以下で見ていきましょう。
ActiveRecordが備える機能
オブジェクトのインスタンスが表の1行に対応し、オブジェクトは表にアクセスするためのインターフェイスを備えています。
Railsでは、このアプローチに沿ったO/Rマッピングの仕組みであるActiveRecordを持っています。Active Recordという言葉そのものはO/Rマッピング全般での上記のようなしくみを指しますが、本稿では、特に断りなく、ActiveRecordと記した場合はRailsで実装されているActiveRecord機能を指すこととします。
ActiveRecordでは、Rubyのクラスをデータベースの表にマッピングし、クラスのメソッドを使用して表にアクセスします。例えば、主キー列としてid列、name列を持ったusers表をUserクラスにマッピングした場合、書式1〜3のようなメソッドで表にアクセスできます。
user = User.find(1) データベースのusers表のId=1の行を検索 user.name = 'suzuki' Userオブジェクトの変数を変更 user.save データベースのusers表のId=1の行のnameを 'suzuki'に更新
次のように条件を付けて検索することも可能です(書式2)。
user = User.find(:all, :conditions => "name = 'suzuki'")
さらに簡単に書くことも可能です(書式2)。
user = User.find_all_by_name("suzuki")
ActiveRecordで表を作成する
ActiveRecordは表へのアクセスだけでなく、表の作成も行えます。前回、rake db:migrate を実行する際に使用したスクリプトの中身をサンプル1に示します。
class CreateUsers < ActiveRecord::Migration def self.up create_table :users do |t| t.string :name t.string :email t.date :hire_date t.timestamps end end def self.down drop_table :users end end
DB2での主キーの扱い
サンプル1では、ActiveRecord::Migrationを継承したCreateUsersクラスでusers表を作成しています。
このスクリプトには主キー列の定義が見当たりません。しかし、データベースに作成されたusers表には主キー列としてid列が作成されています。このid列はDB2ではINTEGERのID生成列として定義されており、行の挿入時にユニークな整数値がid列に追加されていきます。
以下、ID生成列と表記した際はDB2が整数値を生成する機能を指すとします。ActiveRecordでは、表のアクセスに主キー列が必要となります。デフォルトでは、この主キー列は「id」という名前の列です。
次からは、レガシー表をActiveRecordにマッピングする方法を見ていきます。主キー列をいかに扱うかが鍵となります。今回は特に、以下のケースについてご紹介します。
- ケース1:レガシー表の主キー列がINTEGER型やBIGINT型の場合
主キー列にID生成列の定義を追加します。主キー列や表名が異なる場合は、ビューを用いたり、モデルのオプションで表名や列名を指定します - ケース2:レガシー表の主キー列がSMALLINT型の場合
ビューを使用して主キー列をINTEGER型にキャストします - ケース3:レガシー表の主キー列が文字列型または存在しない場合
ID生成列である主キー列を持つ表を作成し、データを移動します
上記のうち、ケース3の方法を使用すればどんなレガシー表に対しても対応が可能です。しかし、表の再作成とデータの移動が不可能なケースも考えられます。
そこで、今回は1、2のようになるべく既存のデータに手を加えずに実現する方法から見ていきます。
ちなみに、3については、表の再作成以外にも、トリガの設定で追加したid列のユニークな値を生成するなど、場合によっては採用可能なさまざまな手法が考えられますが、今回は最もシンプルな方法のみを示します。
1/4 |
Railsでレガシーデータを蘇えらせるテクニック
・ActiveRecordを使ったマッピング
ActiveRecordが備える機能|ActiveRecordで表を作成する|DB2での主キーの扱い
レガシー表に主キー列に相当するINTEGER型やBIGINT型の列が存在する場合
レガシー表の内容を確認|主キー列をID生成列に変更する|主キー列と表の名前をRails規約に一致させる2つの方法
レガシー表に主キー列に相当する列が存在するがMALLINT型の場合
ケース3:
レガシー表に主キー列に相当する列が存在しない、もしくは存在してもCHAR型やVARCHAR型の場合
コラム:読み込み専用の表としてアクセスさせたい場合
・まとめ
DB2でさくさく実現するRESTfulなDBアプリ |
- Oracleライセンス「SE2」検証 CPUスレッド数制限はどんな仕組みで制御されるのか (2017/7/26)
データベース管理システムの運用でトラブルが発生したらどうするか。DBサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle SE2の「CPUスレッド数制限」がどんな仕組みで行われるのかを検証します - ドメイン参加後、SQL Serverが起動しなくなった (2017/7/24)
本連載では、「SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ドメイン参加後にSQL Serverが起動しなくなった場合の対処方法」を解説します - さらに高度なSQL実行計画の取得」のために理解しておくべきこと (2017/7/21)
日本オラクルのデータベーススペシャリストが「DBAがすぐ実践できる即効テクニック」を紹介する本連載。今回は「より高度なSQL実行計画を取得するために、理解しておいてほしいこと」を解説します - データベースセキュリティが「各種ガイドライン」に記載され始めている事実 (2017/7/20)
本連載では、「データベースセキュリティに必要な対策」を学び、DBMSでの「具体的な実装方法」や「Tips」などを紹介していきます。今回は、「各種ガイドラインが示すコンプライアンス要件に、データベースのセキュリティはどのように記載されているのか」を解説します
|
|