勝手に図解するmemcached
先日、Brian Akerとミクシィの前坂氏によるmemcachedのセミナーがあった。 実践で使用する上での話や開発最前線の話が聴けたため、セミナーは非常に盛況であった。筆者にとっても非常に勉強になる内容だった。セミナーの資料はBrian Aker氏のサイトから入手できるのでセミナーに参加出来なかったひとはこの資料を読んで自習して頂きたい。 が、いかんせん氏のスライドはパッと見ただけではなんとなく分かりづらいように俺は思う。なぜだろうか？それはきっと図がないからだ・・・と勝手に想像する。オトコたるもの、時には勝手な憶測で突き進むのもアリだ。ちなみにBrianのスライドはほとんど要点の箇条書きになっている。これでは解説がないと、特に新規にmemcachedやMySQLを学習している人たちには分かりづらいだろう。 というわけで氏に代わり、memcachedがどのように既存の仕組みを置き換える
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
ヒゲモジャのギークが提案する技術習得戦略
先月、Dbtech Showcaseで松信さんがデータベース技術の羅針盤という講演をされた。残念ながらプレゼンそのものを観に行くことはできなかったが、その前の日に松信さんと一緒に昼飯を食べたとき、講演のあらすじについては伺っていた。その際にも同じようなことを松信さんには言ったのだが、スライドを見直した上で改めて自分の意見をまとめておこうと思ったので筆をとることにする。 なお、このエントリではスライドに書かれているトピックについて語るので、まだ松信さんのスライドを見てない人は先にスライドに目を通してから本エントリを読んで欲しいと思う。結論は全く違った方向に進んで行くが、その点は了承して頂きたい。 あなたに選択肢はあるか？ひと握りの天才なら自分の興味のある分野を開拓することができるだろう。あるいはすでに成功を収めた人であれば転職に困ることはないので、成功しそうな会社に乗り換えることもできるだろ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
