同じデータベースにアクセスするいくつかの技術があります。現時点では、Ruby/Railsは、データベースを変更する際にマイグレーションを作成するために使用されます。質問は簡単なものですRuby/Rails以外のデータベースの変更
DBAがRuby開発者の足を踏んでRuby Webアプリケーションを壊すことなく、データベースを変更することは可能ですか（Rubyの移行を使用しないでください）？
もしそうなら、始める方法や正しい方向を指す方法についての一般的な詳細はすばらしいでしょう！ありがとう。
私はこれが最良のアイデアではないことを経験から教えてくれるでしょう。あなたが後悔し、後で、必然的に逆転するということです。しかし、私はそれが起こることを知っています。私はそれらをやらなければなりませんでした（私の意志や極端な緊急事態に備えて）。
オプションを指定すると、SQLをリポジトリに近づけ、データベースへの直接の「クイックフィックス」から遠ざけるソリューションを好むことができれば、それをプッシュバックします。どうして？
1）あなたのローカル/テスト/ステージング/本番データベースは、最終的に
2信頼性の高い方法でテスト不能コードをレンダリングし、発散する）あなたは、生産を一致させるために「スクラッチ」からデータベースを再生成することができません
3）データベースが壊れている場合は、賢明な方法でデータベースを再作成することはできません。
DBAは、コード内の何かが壊れるまでこれらのことを気にしません。しかし、明白な理由から、今は非常に困難になります。
1）コードをリポジトリに入れ大小すべてのデータベース変更を、有することにコミット：誰もが幸せに思える私が取った
一つのアプローチは、次の操作を行うことです。これは、データベースに起こったすべてがすべて1か所にまとめられていることを意味します。
2）各変更または一連の変更は、移行でなければなりません。移行は単にSQLファイルを実行するだけです。しかし、すべてのテスト容易性のために移行内から実行する必要があります。あなたが変更またはSQL経由での変更のセットを作りたいとしましょう、今
- database_updates
-- v1
--- change_1.sql
--- change_2.sql
-- v2
--- change_3.sql
--- change_2_fix.sql
：
したがって、たとえば、あなたはのようなフォルダ構造を持っているとしましょう。まず、新しいバージョンのフォルダを作成し、それを "v1"としましょう。次に、SQLスクリプトをこのフォルダに配置します。最後に、移行を作成します。
def change
# Read all files in v1 folder, and run the SQL
end
各移行がトランザクションであるので、失敗したスクリプトのいずれか（私はあなたがこのアプローチを使用して自分自身を見つける場合は要点を共有する幸せこれを実行するコードを、持っています）それらのすべてが失敗するでしょう。
次に、次のセットv2があるとしましょう。同じこと。これらの「バージョン管理された」変更の履歴があり、移行履歴を確認して何が実行されているかを見ることができます。
パワーユーザーのメモとして、この設定では、 V1、仕事に
このためdef up
# run v2 scripts
end
def down
# run v1 scripts
end
とv2は自律的である必要がある - つまり、彼らは依存せずに実体を破壊し、再構築することができます。これらのケースでは、我々は戻ってV1に行くことを選ぶことができます。それがあなたが望んでいない場合は、changeメソッドを使用してください。
これにより、改ざんの変化をテストすることもできます。 v6でもう何も動作しないことが報告されたとしましょう。データベース移行をv5、v4などにロールバックすることができます（フォルダごとの移行を行っているため）。テストが破られたことを確認してv7で修正します。
とにかく、このプロジェクトをリポジトリから安全にチェックアウトし、データベースを作成し、rake db:migrateを実行し、データベース構造が他の場所に配置されているものと似ていることが分かります。そして、最悪の場合、データベースが壊れてしまった場合は、v1 - vNからすべてのスクリプトを実行し、データベースをもう一度やり直すことができます。
DBAのすべてがSQLのままであるため、実行するファイルまたはファイルのセットを送信できます。
ファンシーにしたい場合は、反復的な定型句を処理するためにrails g migration UpdateDBVersion version:v7のような行を処理する方法を知っているマイグレーションジェネレータを作成することもできます。
誰もが同じ更新版schema.rbまたはstructure.sqlに依存している限り、誰もが同じデータベース 'バージョン'を共有します。
この詳細については、SO answerを参照してください。
私は、データベースの移行とスキーマがチェックインされたコードの一部であるため、DBの変更はエンジニアリングの領域にあるべきだと主張します。 DBAの変更が必要な場合は、標準的な方法で移行し、リリース前にアプリケーションでテストする必要があります。これが、DBAが急激な変化をもたらさないようにする唯一の方法です。 – Mitch
@Mitchこれは、データベース（DBAとコントリビュータ）を使用して作業するすべてのチームがすべてRailsを使用していると仮定しています。時にはこれは起こらないことがあります。また、GUIまたは古い形式のSQLコマンドラインインターフェイスを使用して、修正プログラムをデータベースに直接適用する方が速いこともあります。 – vol7ron
可能であれば、ActiveRecordの移行を使用して、データベース、テーブル、またはインデックスの変更を行う必要があります。これにより、開発環境とテスト環境が論理的に同期していることが保証されます。開発者は、本番環境で発生するのと同じデータベース構造に対して正確な開発とテストが可能でなければならず、QAチームはそのような変更を適切にテストできる必要があります。
ただし、一部のデータベース機能はActiveRecordの移行では実際にはサポートされていないため、データベースに直接適用する必要があります。
ActiveRecord抽象化を持たないデータベース固有の機能は、基本的にデータベースに直接作成されます。
ただし、他のアプリケーションでは、適切または効率的に動作するために、表、列、または索引を追加する必要があることがあります。これらの他のアプリケーションは、単にデータベースに対して閲覧/レポートするために使用することも、独自のデータベース要件と独立した開発チームを持つ実質的なビジネスアプリケーションでもかまいません。 DBAは、現実の生産パフォーマンスの問題を解決するために必要なステップを踏んだり、インデックスを作成したり、最適化を提供しなければならないことがあります。
共有データベース管理では、決定的な回答を得るにはあまりにも多くの状況があります。組織の規模と共有管理のニーズの複雑さに応じて、アプリケーションまたは組織に固有の共有データベーススキーマの問題を解決する方法は多数あります。
例えば、私はDBAグループを介して仲介されている他のチームと他のチームと共有されている、他の10個のアプリケーションを共有するアプリケーションに取り組んできました。このような状況では、組織構造と変更管理プロセスがこの問題を解決する唯一の手段である可能性があります。状況は、いくつかの実世界の提案は、問題を避けるため、メンテナンス苦境を軽減することがどちら
：DBAが自分のニーズを達成することができるように、可能な場合はSQL DDLは、ActiveRecordの移行にコマンドを翻訳する
この質問は、スーパーユーザフォーラムの方が多いですが、まだプログラミング関連です。私はそれが幅広い組織開発チームとの共通の出来事であると考えています。おそらく、ここで注目を集めるべきです。だから、もしそれが終わったら、私はそれを開いたままにしておくつもりです。 – vol7ron
うん、私は実際にこの種のものによって引き起こされた穴から実際に掘り起こさなければならなかった、間違いなく起こる...それ以上のものIMO。 – GoGoCarl