データモデル自体はアジャイルなのだが... - 極北データモデリング
全体に与える影響が極めて大きく、後戻りしにくい「スポンジ層」というのが存在する。そのひとつが渡辺さんの言われているデータモデルである。 データモデリングなきアジャイル開発は危ういか？：An Agile Way 平鍋さんが「(業務システムの)データモデルの変更コストは非常に高い」という意味のことを書かれている。これについて。 データモデル自体の変更コストは非常に低く、後戻りし放題である。新しいスキーマでcreate tableして、データをロードして、drop table/rename tableするだけだからな。 しかし、データモデルに手を入れるためには、同時に既存アプリケーションへの影響を調査して、漏れなく修正しなければならない。 プロジェクトが進行するほど、データモデル改変の影響範囲は広がり、修正点も増えていくだろう(元記事でデータモデルを「高リスク制約」つまり「プロジェクト開始からの
プロとアマの境目について語るな。一流と二流の違いを語れ - 極北データモデリング
勝手ながら補足させていただくと、 手塚貴晴さんという建築家がいる。一種の天才なのだと思うのだが、5年ほど前、TVで見た光景が忘れられない。 部下の設計者が徹夜で作ってきた建築模型を一目見るなり「これはゴミだね」と言って、ガシャリと壊してしまったのだ。 僕はそのころ駆け出しコンサルタントになったばかりで、部下の人の痛みがよく分かった。 それと同時に、本当にたくさんのことも学んだ。 あなたの作ったものはゴミである、あるいはプロとアマの分岐点 これをやっていいのは一流だけだ。「私は一流だ」と言い切れない程度の人間は絶対にやってはならない。 理由は書かないが、書かなくても同意してもらえるのではないかと思う。 そして問題のプロ論。 そして、「頑張ること」それ自体に価値があるのはアマチュアの世界、価値がないのがプロフェッショナルの世界である。 全ての人がプロフェッショナル的に仕事をするべきだ、とは僕は
忘れてしまったほうがいいSQLチューニングテクニックについて - 極北データモデリング
10年ぐらい前はJavaで文字列を連結するときは String ではなく StringBuffer を使ったほうが速いなんて言われてたんだけど、それがテクニックとして有効だったのは「StringBufferを使えばこれこれの内部動作になる」という関係が固定されていたからで、仮にJVMのリビジョンによってどっちが速いかがコロコロ変わったり、文字列の長さが一定以上になると突然あっちの方が速くなったり、みたいな状態だったら「文字列の連結はStringBufferの方が...」はテクニックとして成り立たなくなってしまう。 が、SQLについての言説の一部はまさにこの状態で、本来成り立たないことがチューニングテクニックとして語られていると思う。 そういうのを暗記するのはやめて実行計画を見ましょう、という話。 「INとEXISTSはどっちが速いか」の不毛 昔から「INを等価なEXISTSに書き換えると速
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
