まあ、サクサクタイプかな?

今日は虎ノ門までお出かけでした(´ー`)
その行き帰りの電車で読んだ本について(・∀・)

受託開発の極意―変化はあなたから始まる。現場から学ぶ実践手法 (WEB+DB PRESS plusシリーズ)

受託開発の極意―変化はあなたから始まる。現場から学ぶ実践手法 (WEB+DB PRESS plusシリーズ)

で、「サクサク」っていうのはパイ生地ではなく、リーダーのカラーの話。
っとこの本のごく一部にのみ反応してみたり(・∀・)


別に中小プロジェクトに限らず、大規模プロジェクトであっても変化に適応することこそ重要だと思っているので(・ω・)*1
大規模プロジェクトと言っても、中には数百〜数千万プロジェクトの集合体みたいなものだってありますしネ。*2
まあ、他のタイプの人と考え方にギャップを感じることもたしかにありますが。*3
例えば、責務とかPM的には正しいのかもしれないし、そのやりかたでも品質を保証することはできるだろうけど、
競争力とか満足度とか利益(売り上げではない)的にはどうなのよ?、って思うような事もあったりして(゚д゚;)*4
ちょっと話がズレたかな(・ω・)?
ちなみに、うちの事業本部長は「バリバリ」タイプ(自分の元々上の人)、事業部長(自分の元上の人)は「よしよし」タイプかも。

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

GFSみたいなものを使いたいですか(・∀・)?
自分はオープンソースで枯れたプロダクトなんかがあれば直ぐにでも使いたいです、っというか、案件のニーズとしてそういうのはありますし。


Web系システムの場合、データベース設計と同じかそれ以上にサーチエンジンやキャッシュの設計も重要だったりするわけで(・ω・)
リレーショナルなデータベースよりも、単一キーによるput/getが出来るだけでよいので、スケーラビリティーに優れた分散ストレージが欲しいというケースは結構多いんじゃないのかしら(・∀・)?*5
MySQLなんかをそれっぽい用途に使っている事もあるだろうし。


あと、サーチエンジンに限った話で言えば、製品でこういう構造を持ったものもあったりするわけですが。
でも、そういう製品は価格の面でスケーラビリティーに優れないのよね〜(・∀・;)
検索性能の上限は予算によって決まります、なんて(^Д^)
クローラ、インデクサ−、結果サーバとかは、必要に応じて普通のラックマウントを増やして対応したいと思うわけですが(・ω・)


あと、この2冊を買う時にコレも買いました。

データベース・リファクタリング

データベース・リファクタリング

  • 作者: スコット W アンブラー,ピラモド・サダラージ,梅澤真史,越智典子,小黒直樹
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2008/03/26
  • メディア: 単行本
  • 購入: 10人 クリック: 211回
  • この商品を含むブログ (53件) を見る

チェックしてあったんだけど、買うのを忘れてた(´・ω・`)


ところで最近、DBの構成管理はどういうやりかたが良いんだろうと考えたりするわけですが。
ソフトウエアの構成管理についてはこういう本もあったりしますが(・ω・)

パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)

パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)

ちなみに最近の自分のDBに関する成果物の管理のしかたはこんなんですが(´・∀・`)
まず、DBに関する成果物としては次のものがあって。

  • ドキュメント(ER図他)
  • データベース構築SQLスクリプト
  • 実際のデータベース
  • データベース処理に関するクラス

これらを次の順番で生成しています。

  1. まず、SQLスクリプトを書く(手で書くこともあれば、DB管理ツール上で色々弄った後に生成することもあり)
  2. そのSQLスクリプトを流してデータベースを構築する(このためのバッチスクリプトとかも用意)
  3. 実際に出来たデータベースをリバースエンジニアリングしてドキュメントを作ったし、クラスを自動生成したり
  4. 設計に変更が入った場合、プログラムの変更とともに上記処理を繰り返す(しょっちゅうDBを初期化しています(・∀・;))

まあ、ExcelやERデザイナーからSQLスクリプトを吐いたり、モデルクラスからDBを構築したりという話はよくあるでしょうけど。
自分はSQLスクリプトというソースが1stにあって、そこから他のものを生成していくというやり方をしています。
そしてSQLスクリプトはプログラムソースと一緒に同期して管理し、修正、確認、コミットというサイクルを繰り返すっと(・∀・)


ちなみに、オマエの所にはDBAはいないんかい?、っと問われれば、いないんですと答えるしかありませんノダ(´・ω・`)
とりあえず中小のプロジェクトは置いておくとして。
大規模なプロジェクトでも、DAではなくDBA(DBプロダクトの技術面に強い人)は、業務と言うよりもインフラチームだし。
モデリングが得意な人なら、DB主幹というよりも機能設計の中心人物になりますしね。
割とアプリケーションよりな考え方になっていますにょ(・ω・)



サクサク言ってたらミルフィーユが食べたくなったヨ(´・ω・`)

*1:そして、そのためにこそ技術力が必要なのですよ(・∀・)

*2:イメージで言うと、ポータルサイトの構築だったら億単位の案件かもしれないけれど、その中のBlogなりSBSなりといった個々の機能は数百万〜の案件でしょうみたいなカンジ

*3:実際の所、規模と言うよりも、やっている仕事の種類によって、最適化する部分が違うよって話なんでしょうけどね

*4:本当を言うと、正しそうに聞こえることよりも面白そうに聞こえることの方が好きなだけですが(´・ω・`)

*5:「業務」的な部分は勿論RDBが欲しいですけど、インフラ系とかは特にね