開発マシンは、最速がいいという場合、ハードメーカーの戦略にも注意しないと。。

　前に「プログラマの権利宣言」だって！っていう話をかきましたけど、その元ねたとなっている、
プログラマの権利宣言
http://www.aoky.net/articles/jeff_atwood/the_programmers_bill_of_rights.htm
には、こんな言葉がある（以下斜体は上記サイトより引用）


すべてのプログラマは高性能なPCを持つべきである
開発者は仕事を成し遂げるためにたくさんのソフトウェアを走らせる必要がある。開発環境、データベースエンジン、Webサーバ、バーチャルマシン、などなど。これらのソフトウェアすべてを動かすには、メモリをたくさん積んだ速いPCが必要になる。開発者のPCが速いほど、彼らのデバッグ&コンパイルサイクルは早くなる。現時点における性能帯の極端にあるものに法外な金を払うのはばかげているが、しかしいつでも必ず上限に近いものを買うようにすることだ。開発者には しこたまメモリを積んだ高速なPCを支給すること。プログレスバーを眺めて過ごす時間は無駄な時間でしかない。


　これは、必ずしもそうとはいえず、真に受けると、取り返しのない大失敗を招くことがあると思うので、ちょっとそのことについて書いてきます。
　それと、そのことから考えると、なぜ、最速マシンを使わないといけない羽目になるかというのがわかるので、それについても。。

---

■コンパイラが特に遅いのでなければ、開発マシンは、実行マシンに合わせたほうがいい

　最速マシンでやってしまうと、いきなりシステムテストで、実行環境でテストしたら、あらまあ、とんでもなく遅かった（＞＿＜！）っていうことになったりする。

　逆に開発マシンがおそいと、これはウィリアムのいたずらがあった実話なんだけど、ＤＢを使った、お昼に流したいバッチ処理に、どーチューニングしても１時間かかり、あちゃー、どーしよー（＞＿＜！）と思っていたら（お昼なので１時間かかるとヤバイのです）、現地でやったら１０分で終わった。。うーん、徹夜でチューニングしなくてもよかったみたい（－＿－）なんていう、むだなチューニングをする可能性もある。

　なので、実際のターゲットマシンでどれくらいの速さで動くかというのをできるだけ早めに知って、そのチューニングがすぐにできるほうがいい。もし、システムテストの段階で、「おそい！」と気がついても、どーにもなんない。。
　作り直すしか手がない、けど時間もない！ということもありえる。

　とすると、開発マシンでＰＧの段階で、もうすでに実際のターゲットマシンをつかって開発したほうがいいってことになる（ＰＧでバイナリが出来た後、すぐにテストできるので）

---

■でも、コンパイルが遅かったら、そうではない

　しかし、実施環境にするとコンパイラがすごく遅くなるとか、そもそも、ターゲットマシンでは開発、コンパイルできないって言う場合もある。こういうときは、最速マシンでコンパイルしたほうが効率は良くなる。ただし、その場合でも、できるだけ早い段階で実施環境に近い形でテストすべきである。ほんと、あとから、「おそい！」っていわれても、もう、どーしょーもないっていうことになるのだ。。

　だから、はやくからターゲットマシンを取得し、確認しておくべきである。

---

■って、考えると、マイクロソフトは最速マシンで開発することになるね！

　っていうことで、「開発マシンはターゲットマシンに合わせる」ってなると、
　仮にマイクロソフトについて考えてみると（って、ウィリアムのいたずらは関係ないけど、まあ、仮に考えてみると）。。。
　現在一番売れているマシンで開発なんかしたら、従来のマシンの性能で、十分なＯＳを開発してしまう。。。これはこまる。

　なぜなら、今のマシンで新しいＯＳも十分動いてしまったら、「じゃあ、今までのマシンで動かして、べつに新しいマシンに買い換える必要ないや！」となってしまい、新しいハードが売れなくなる。。

　マイクロソフトのＯＳは、最新の機種でちょーどよくて、現在の機種では遅くないと、ハードを買い換えてもらえないので、ハードメーカーは新しいＯＳをバンドルして売れなくなる。

　ということで、マイクロソフトの開発者は、きっと最新鋭のマシンで開発することになるだろう。。。と予測できる。

---

■ってことは、新規購入なら、最新マシンで開発したほうがいいってこと。。

　ってことは、マイクロソフトに限らず、業務用でも、リリース時にあたらしくＰＣを買い換えるなら、それにあったマシンで開発する。。といっても、未知のマシンで開発するわけにはいかないので、結局、現状の最速マシンで開発することになる。

　一方、新規購入しないのであれば、ターゲットマシン（実運用で動かすマシン）でコンパイルができるなら、ターゲットマシンで開発、コンパイルできないとか、とっても遅い場合、最新のマシンでコンパイルするけど、テストはシステムテストをまたずに早い段階から、ターゲットマシンで確認したほうがいい。。

　ってことになるだろう。

Hello World程度のデータベース（その１５：内部スキーマ（３）データ置き場）

情報処理とは何から、データベースの基本的な話(情報処理試験のデータベーススペシャリスト程度の話まで）を書く、土日のシリーズ「Hello World程度のデータベース」です。

　今、三層スキーマ構造（概念スキーマ、内部スキーマ、外部スキーマ）の内部スキーマをやっています。
　で、内部スキーマはＤＢの構造の話なんですけど、前々回、そのうち、インデックスとデータの話をすると書きました。前回、インデックスの話をしたので、今回はデータの話です。

---

■データの型

　で、今回は、データベースのデータを置く場所についてです。
　っていっても、データをまあ、テキトーにおいていけばいいわけですが、実際には、コンピューターで文字や記号を表現するとき、整数の場合、小数の場合、文字の場合で違います。文字は日本語と英語でもちがいます。

　っていうことで、データを置くためには、データが、どういう形で入っているかの型を指定します。これは、テーブルで定義します。

---

■行連鎖など。。

　じゃあ、そのデータを型のカタチで格納しましょう。
　レコードごとに格納するとして、追加するとき、領域があるなら、これは、どんどんつぎたしていけばいいですので、かんたんです。
　でも、もし、こんな場合、どうしましょう（話を長簡単にしてるので、実際にはこんな単純なことではないです）。

・５０バイトのレコードを削除しました
・つぎに、３０バイトのほかのレコードを削除しました。
・６０バイトのレコードを追加しようとおもいます。

　上記の５０、３０バイト以外、一切アキがないとします。
　そうすると、６０バイトがないからＸっていうわけじゃなく、６０バイトを分割し、５０バイトと１０バイトなど、アキ領域に入るように分割しちゃうんです。
　こうなると、行が２つの領域にはいっているので、行を連鎖しないと、１行とってこれません（＞＿＜！）これが、行連鎖といいます。

　で、この行連鎖がおこってしまうと、２つの領域（それ以上かもしれないけど）にアクセスしないと、１行とってこれないので、アクセス時間は遅くなってしまいます（＞＿＜！）

どーしましょー。。。。

っていうはなし。

　このほかに、行移行っていうのもあって、それがおこると、アクセス上、おそくなってしまう。
　たいへんです。。

　っていうことで、この行連鎖、行移行については、以下のところにくわしいみたい

データベース・トラブル10選---第2回　パフォーマンスの悪化を食い止める（4）
オプティマイザの挙動を知り，領域管理で“連鎖”や“移行”を防ぐ
http://itpro.nikkeibp.co.jp/members/NOS/TROUBLE/20021031/4/

　なんで、興味ある人は、そっちをみてください。

---

■ＶＳＡＭについて

　で、あと、もうひとつ、今は２０Ｇのハードディスクとかあるので、１つのハードディスクで全部のデータをいれるっていうことができますが、むかしは、こんなに容量がなかったので、複数のハードディスクにデータをいれて、あたかも１つのように、ＤＢでは処理できないといけませんでした。
　この複数ハードディスクをあたかも１つのハードディスクのように扱う技術がＶＳＡＭと言われます。

　いま、そんな必要はないんだけど、逆に言うと、もし、この時代の伝統に従うなら、データベースのデータは、複数箇所に格納されているかもしれないので、どこに散在しているか、宣言しないといけないってことに成りますよね。。（このはなしが、あとできいてくる。。）

---

　ということで、今日のデータについては、簡単ですが、ここまで。
　このシリーズの次回では、実際にデータとインデックスに関して、ＤＢにたいして、どのように操作するのかっていう話をします。

「プログラマの権利宣言」だって！

「プログラマの権利宣言」っていうのがあるそうだ。それを訳したのが

プログラマの権利宣言
http://www.aoky.net/articles/jeff_atwood/the_programmers_bill_of_rights.htm

らしい。それによると（以下斜体は上記サイトより編集して引用）


１．すべてのプログラマは2つのモニタを持つ権利を有する
２．すべてのプログラマは高性能なPCを持つべきである
３．すべてのプログラマはマウスとキーボードの選択の権利を有する
４．すべてのプログラマは快適な椅子を持つべきである
５．すべてのプログラマは高速なインターネット接続を持つべきである
６．すべてのプログラマは静かなる仕事環境を持つべきである


うーん、どーなのかなあ？なんか、違う世界の話だ。。
６番以外は、そんなことをするなら、他のもっと人として生きることを許される権利を認めて欲しいと思うなあ。。

もっと、人間として基本的な権利の確保を、ウィリアムのいたずらなら要求します。

こんなかんじ

１．すべてのプログラマは、寝る時間が確保されるべきである
２．すべてのプログラマは、効率的に働けるべきである（＝無駄に待機させない）
３．すべてのプログラマは、土日は「休み」を選択する権利を有する
４．すべてのプログラマは、家に帰れないなら、快適に寝られる場所を持つべきである
５．すべてのプログラマは、インターネットを見ていいことにすべきである
６．すべてのプログラマは、静かなる仕事環境を持つべきである

ちょっと説明すると。。（上記プログラマの権利宣言と比較してみてね　＾＾；番号ごとに対応）

---

１．すべてのプログラマは、寝る時間が確保されるべきである
　寝ないことによる下落する生産性（ちょっとしたことでも間違えバグが増える）と、遍く利用されるタクシーの費用を考えたら、開発者を１つの開発現場に長時間制限して、終電以降に帰らせ、寝させないのはばかげた話だ。開発者の生産性を最大限にしたいと思うなら、それぞれの開発者が間違いなく６時間は寝させて、仕事が終わらないなら、２交代制にすべきだ。

２．すべてのプログラマは、効率的に働けるべきである（＝無駄に待機させない）
　開発者は仕事を成し遂げるために、たくさんやらなきゃいけないことがある。打ち合わせ、プログラム、テスト、雑用、ドキュメントかきなどなど。これらを効率的に行うには、効率的に動けるようなスケジュール、待ち時間（待機時間）の減少が必要になる。
　マネージャーのスケジューリング、段取りがいいほど、彼らの仕事のスピードは、早くなる。
　スケジューリングに悩みすぎる。。っていうのはやりすぎだが、しかし、いつでも、マネージャーは、開発者の段取り、開発者間のつなぎについて、できるかぎりの神経を使うべきだ。
　開発者に、手待ちぶたさに、なにもやらせない時間をつくらないこと。
　テストのために、ずーっと待機して、結局何もしないのに、徹夜させられるのは、無駄な時間でしかない。

３．すべてのプログラマは、土日は「休み」を選択する権利を有する
　大学を卒業後、私はソフトハウスに入ったが、そこでは、ちゃんと土日が休める会社だった（ほんとの話です）。これは私が最初に学んだことだった。新入りの社員に土日も出社させて、ショーもない仕事をさせてもうまくいかない。 「会社の」雑用仕事は、テキトーに仕事させられ、結局技術として身につかない。しかし、開発者は、土日をお休みにすれば自分で勉強する（多くの人は、そう）。土日に休んだ開発者は、開発全体の流れと、実際の仕事の雑用との間の関係を学ぶ。土日を休みにすることで、揺るぎない基本的技術と開発者の感覚が生まれる。プログラマで現在お仕事してる人も、自分のお休みに対して、土日を休んでいいという会社との関係を持つべきだ。それは私たちの技を行う上で必須なお休みなのであり、そのようなものとして「会社は土日を」扱うべきなのだ。
（土日出社が当たり前と思う感覚が、おかしいと思うべきである）

４．すべてのプログラマは、家に帰れないなら、快適に寝られる場所を持つべきである
　現実に目を向けよう。我々は帰れないと、大方どこかで寝ている。どうしてその睡眠時間を快適に、ちゃんと寝られる環境で過ごさないんだ? 開発者には睡眠時間、インターネットカフェのいすや机の上、いすを何個か並べたようなどうにか耐えられる（いや、耐えなれない）寝る場所ではなく、ちゃんと、起きたとき、寝て疲れがとれる、楽になるような、寝られる場所を確保するべきである。
確かに開発者を雇うのは主としてその人が仕事をするためではあるが、開発者が仕事をするために必要な睡眠を確保するための資産も粗末にしないことだ。

５．すべてのプログラマは、インターネットを見ていいことにすべきである
　いいプログラマは悩んだら、他の人や本などにある情報を入手しようとする。そしてインターネットはかつて発明された中で最高の情報入手経路だ。私は紙で書いてあるほうが好きだが、それでも指先に高速でいい反応をしてくれるインターネット検索なくして、何らかの仕事を成し遂げるというのは想像し難く思う。
（だから、仕事に関係のあるものは、みていいことにすべきです。なんか、最近、全面的にインターネット禁止、ダウンロード禁止の会社がある　＞＿＜！）

６．すべてのプログラマは、静かなる仕事環境を持つべきである
プログラマは精神的集中を必要とする。プログラマは割り込み駆動の環境で効率的に仕事することはできない。仕事環境がプログラマのフロー状態を守れるように気を使うことだ。そうでないと、彼らはほとんどの時間を、気を散らすものの間で跳ね回って過ごすことになる。
（これは、もとのプログラマの権利宣言とおなじです）

---

これ以下のことは、元の「プログラマの権利宣言」に書かれていることまったく同じです。

私たちが求めているわずかの権利を認めるのは簡単なことだ。無茶な要求なんかしていない。これはソフトウェア開発者の仕事生活の質のために根本的なことなのだ。あなたの会社でこれが正しく為されていないなら、それを正すのは高くもなければ難しくもない。プログラマとしての権利を主張しよう! そして覚えておいてほしい。あなたは会社を変えることもできるし、「会社を変える」こともできるのだ


　っていうか、ウィリアムのいたずらが言う、上記のことは、むしろ、守るほうが、本当は経営陣はもうかる（２交代制にして、家に帰れるようにすれば、生産性はあがるし、タクシー代、宿泊代は入らないし、残業代もないし（１人１６時間と２人で８時間だと、残業の超過賃金分、１人でやったほうが高くなる）。。）んだけどね。。