Railsプロジェクトの初期開発フェーズでのDBスキーマ管理を見直す | Webシステム開発／教育ソリューションのタイムインターメディア
DBのスキーマ、皆様どのように管理されているでしょうか。 Railsを利用されている方の多くは、ActiveRecordのマイグレーションを利用して管理をされているかと思います。 私もいままでいくつかのRailsプロジェクトに関わってきましたが、 ほぼ全てのプロジェクトでActiveRecordのDBマイグレーションを利用してきました。 (一部のプロジェクトはActiveRecordを使っていないため、マイグレーションも独自のものを利用しています) ActiveRecordのマイグレーションでは、DBスキーマ変更の差分情報をマイグレーションスクリプトとして保存しておきます。例えば、新しいテーブル「users」を作成する場合は、下記のようなマイグレーションスクリプトを作成します。 class AddUsers < ActiveRecord::Migration def up # ここにマイグ
EC2のt1.microをt2.microへ移行する : アジャイル株式会社
手順の概要は下図のようになります。 注意事項 コピー元は実稼働しているインスタンスを利用するのではなく、インスタンスのコピー（スナップショット）を作成し、これで作業するようにしましょう。 作業に失敗したりした場合、インスタンスを破壊する可能性があります。 作成するVolumeとInstanceのAvailability Zone は併せましょう。 ap-northeast-1a/1c が混在するとアタッチできなくて作業のやり直しが増えます ( 経験者談 )。 PV に grub をインストールする 移行元の t1.microインスタンス (以下 コピー元インスタンス) に grub をインストールします。 $ sudo yum install grub コピー元インスタンスのスナップショットを取得する awsのマネジメントコンソールから、EC2に移動します。 メニューから [ ELASTI
気軽なMySQLバージョンアップ - まめ畑
このエントリーはMySQL Casual Advent Calendar 2013 10日目の記事です。カジュアル！ このへんでそろっとカジュアル詐欺と言われるのを防止するために、カジュアルな話を書いてみました。 MySQL5.6も正式リリースされてもうすぐ1年経ち、5.7の足音も聞こえてきている今日このごろですが皆様のMySQLのご機嫌はいかがでしょうか。 新機能や性能向上/bugfixに対応するためにMySQLのバージョンアップを行う機会や性能や不具合調査を行うことも多いかと思います。データベースのバージョンアップは特にメジャーバージョンアップの場合、パラメータのデフォルト値などの変更や仕様変更の影響(オプティマイザの変更)をアプリケーションが受けないか、性能の変化などを検証すると思います。 検証 実際に検証を行う場合、本番環境で流れているクエリをバージョンアップ先のDBに実際に流して
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DBスキーマもバージョン管理したい！
