unavoidable.これまでの議論であなたはきっと自分のローカル開発環境に自分専用のデータベース環境のコピーを用意すべきだと確信してくれたと思う。あなたがどれだけ頑張っても、開発チームの全員がひとつのデータベース環境で開発すれば、必ずコンフリクトが発生するはずだ。最近、私の顧客の一人が開発用データベースを共有するというパターンを選択した。経験豊富な3人の開発者で構成された小さな開発チームで、全員が一カ所のオフィスで席を並べて座っていたにもかかわらず、コードとデータベースの同期を維持することはできず、頻繁にコンフリクトが発生した。データベースを分離していなければ、こうした問題の発生は避けられないのだ。worth?ローカルマシン上でデータベースのコピーを実行させることはもちろん可能だ。Editionなら無料で手に入る。SQLプロファイラーが存在しないといったいくつかの制約はあるが、AnjLabのような優れた無料のプロファイラーツールも存在している。それでも全機能が必要だというのであれば、Developerエディションは50ドル以下で手に入る。comes.また、もしかするとあなたのマシンは十分なメモリを積んでいないかもしれない。2007を動かしていたりするとマシンは非常に重くなる。3GBか4GBぐらいのメモリを積んでいれば十分動作するということに私は気づいた。最近であればみなさんはそれぐらいのメモリを積んでいないのだろうか?雇い主はあなたのことを高価な使用人だと考え、あなたの生産性を向上させるのに必要な追加の数百ドルを正当化できないために、あなた方の多くは粗末な古いマシンしか与えられていないのだろう。その場合、我々がここで解決しようとしているどの問題よりも大きな問題をあなたは抱えていることになる。可能であれば数百ドルかそれ以上のお金を自分のマシンにつぎ込んでみるべきだと私は言いたい。それが仕事で使うマシンで、会社がつぎ込んだお金を立て替えてくれないとしてもだ。いうアイデアには多くの人々が信条に反するとしてきっと反対するだろうが、そういう信条の人々は自分たちで小さなグループを作って仲間が来るのを待つのがいいかもしれない。machine.とはいえ、克服しがたい潜在的な問題も存在する。既存のデータベースがあまりに大きすぎてローカル環境では実行できないとしたらどうだろう?とある顧客は関連性のない無数の目的のためにプロダクションデータベースを使っていて、そのサイズは30GBもあった。別の顧客はそれぞれ約300GBもある二つのデータベースに莫大なビジネスデータの大半を溜め込んでいた。データベースがあまりにも巨大すぎてローカル環境にコピーできないという状況は時々発生するものだ。situation.この問題に対処する方法はいくつか存在する。最善の解決策のひとつはスキーマとデータを分離することだ。300GBもあるデータの中からどんどんデータを取り除いていって、アプリケーションを実行するのに必要な最小限のサンプルデータを切り出すのだ。データを完全にクリアして、サンプルデータを生成するスクリプトや自動化テストを用意するという手もあるかもしれない。この手法を用いる場合、どんなデータが必要でどんな目的で使われているのかという長い解析時間を要することが多い。それは悪い話でもない。データの使われ方に関する理解を深めながら手頃なサイズの開発用データベースを切り出すことは非常に有益なことだ。考えてもこれは楽な仕事ではない。いえ実行可能ではあるだろう。すべてはあなたの状況次第である。data.もうひとつの選択肢はハイパワーな開発用データベースサーバーを一台セットアップし、開発者一人一人に専用のインスタンスを割り当てることだ。この手法には問題点もある。それはどのインスタンスが誰のものなのか分かりにくくなるとか、テラバイト級のデータを格納するのに十分なディスクスペースを確保できるのかといったことだ。はてなブログPro株式会社ソニックガーデンで働くRubyプログラマ。2017年11月に「プロを目指す人のためのRuby入門」を出版。blog)はてなブログをはじめよう!JunichiItoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。