Running with a Local development database.
ローカル開発環境のデータベースで実行する
Hopefully I’ve convinced you that you should have your own copy of the database for your local development. No matter how hard you try, if you have a whole development team working in a single database, you will inevitably run into conflicts. Just recently a client of mine followed this pattern of shared development databases, and our team was constantly breaking each other because the code and database was out of sync, even though we were just a small team of 3 experienced and practical developers sitting together in a single office right next to each other, working together well and communicating all day, but the lack of database isolation made the issues unavoidable.
これまでの議論であなたはきっと自分のローカル開発環境に自分専用のデータベース環境のコピーを用意すべきだと確信してくれたと思う。あなたがどれだけ頑張っても、開発チームの全員がひとつのデータベース環境で開発すれば、必ずコンフリクトが発生するはずだ。つい最近、私の顧客の一人が開発用データベースを共有するというパターンを選択した。経験豊富な3人の開発者で構成された小さな開発チームで、全員が一カ所のオフィスで席を並べて座っていたにもかかわらず、コードとデータベースの同期を維持することはできず、頻繁にコンフリクトが発生した。データベースを分離していなければ、こうした問題の発生は避けられないのだ。
Of course, you can run a local copy of the database. SQL Server Express Edition is free. Sure, it has some limitations, like the lack of a SQL profiler, but there are great free tools out there like the one from AnjLab. And if you still need a full-featured copy, the developer edition costs less than $50. Can you or your company not spare $50 for something like that that could have save your hours of debugging? Really? How little do you figure your time is really worth?
ローカルマシン上でデータベースのコピーを実行させることはもちろん可能だ。SQL Server Express Editionなら無料で手に入る。SQLプロファイラーが存在しないといったいくつかの制約はあるが、AnjLabのような優れた無料のプロファイラーツールも存在している。それでも全機能が必要だというのであれば、Developerエディションは50ドル以下で手に入る。デバッグにかかる工数が大きく削減できるというのに、あなたやあなたの会社は50ドルという金額を出し惜しみするだろうか？本当に出し惜しみする？あなたは自分の時間の価値をどれくらい過小評価しているんだい？
Or maybe your machine doesn’t have enough memory. It’s true, SQL will eat up memory like nobody’s business and if you have Visual Studio 2008 and Outlook 2007 running, it can be pretty heavy. But I’ve found that as long as you have 3 or 4 GB of RAM, it works pretty well, and doesn’t everyone have that these days? Sure, a lot of you are stuck with crappy old machines that your employer gave you because he considers you to be a high-priced janitor, and he can’t justify in his mind spending a few hundred extra to make help you be more productive, but in that case you have bigger problems than anything we’re going to solve here. I would say, if possible, you should even shell out a few hundred and get some more memory for your machine, even if it’s a work machine and they won’t reimburse you for it. I know plenty of people who would be opposed to this just out of principle, but those people and their principles can go have their own little pity party and see who comes.
また、もしかするとあなたのマシンは十分なメモリを積んでいないかもしれない。SQL Serverがとてつもなくメモリを食うのは確かだし、もしVisual Studio 2008とOutlook 2007を動かしていたりするとマシンは非常に重くなる。しかし、3GBか4GBぐらいのメモリを積んでいれば十分動作するということに私は気づいた。最近であればみなさんはそれぐらいのメモリを積んでいないのだろうか？雇い主はあなたのことを高価な使用人だと考え、あなたの生産性を向上させるのに必要な追加の数百ドルを正当化できないために、あなた方の多くは粗末な古いマシンしか与えられていないのだろう。しかしその場合、我々がここで解決しようとしているどの問題よりも大きな問題をあなたは抱えていることになる。可能であれば数百ドルかそれ以上のお金を自分のマシンにつぎ込んでみるべきだと私は言いたい。たとえそれが仕事で使うマシンで、会社がつぎ込んだお金を立て替えてくれないとしてもだ。こういうアイデアには多くの人々が信条に反するとしてきっと反対するだろうが、そういう信条の人々は自分たちで小さなグループを作って仲間が来るのを待つのがいいかもしれない。
However there is certainly one potential problem that can be difficult to overcome. What if your existing database is just too damn big to run locally? One recent client had a production database which was used for a million unrelated purposes, and it was 30GB. Another recent client had the vast majority of their of their business data spread across two databases that were each about 300 GB. Sometimes, the database is just too big to copy down to your local machine.
とはいえ、克服しがたい潜在的な問題も存在する。もし既存のデータベースがあまりに大きすぎてローカル環境では実行できないとしたらどうだろう？とある顧客は関連性のない無数の目的のためにプロダクションデータベースを使っていて、そのサイズは30GBもあった。別の顧客はそれぞれ約300GBもある二つのデータベースに莫大なビジネスデータの大半を溜め込んでいた。データベースがあまりにも巨大すぎてローカル環境にコピーできないという状況は時々発生するものだ。
There are a few ways to deal with the problem. Sometimes the best option is to separate the schema and the data. Strip down the data, get rid of the 300 GB, and get the minimum amount of sample data necessary to run your applications. Maybe clear it out entirely, and have some scripts or automated tests that generate a batch of sample data. Often times this will require a lot of analysis to determine what is necessary, and what all of the data is being used for, but that’s not an entirely bad thing. If you get a good and portable development database out of it, while also getting a better understanding of how the data is being used, then that has a lot of benefits. Granted, this is not easy by any stretch, but it may be do-able. It all depends on your situation.
この問題に対処する方法はいくつか存在する。最善の解決策のひとつはスキーマとデータを分離することだ。300GBもあるデータの中からどんどんデータを取り除いていって、アプリケーションを実行するのに必要な最小限のサンプルデータを切り出すのだ。もしくはデータを完全にクリアして、サンプルデータを生成するスクリプトや自動化テストを用意するという手もあるかもしれない。この手法を用いる場合、どんなデータが必要でどんな目的で使われているのかという長い解析時間を要することが多い。しかしそれは悪い話でもない。データの使われ方に関する理解を深めながら手頃なサイズの開発用データベースを切り出すことは非常に有益なことだ。もちろん、どう考えてもこれは楽な仕事ではない。とはいえ実行可能ではあるだろう。すべてはあなたの状況次第である。
Another option is to setup a single high-powered development database server, and give each developer their own instance of the database on the server. This approach can have its own problems as well, such as people getting confused about which database instance belongs to who, and having enough disk space to store the inevitable terabytes of data.
もうひとつの選択肢はハイパワーな開発用データベースサーバーを一台セットアップし、開発者一人一人に専用のインスタンスを割り当てることだ。この手法には問題点もある。それはどのインスタンスが誰のものなのか分かりにくくなるとか、テラバイト級のデータを格納するのに十分なディスクスペースを確保できるのかといったことだ。
