TIL: 数値をあえて文字列型で保存することがある - @kyanny's blog
列1 列2 列3 列4 eb2c0958-991c-5f26-4d99-8214518fbb8a a 20000 5000 66a08082-ebd0-6de2-c4e8-6388df00e4e5 b 20000 5000 このようなデータを持つ CSV ファイルをパースして RDBMS のテーブルに保存する。列2の値がaならテーブルAに、bならテーブルBに保存する。 テーブルAの各行は、列3と列4の値を数値計算に利用する。テーブルBの各行は、行が存在することにのみ意味があり、列3も列4も数値計算には利用しない。 このような前提で、テーブルBの列3と列4のデータ型が文字列型になっていた。テーブルAの列3と列4は数値型なのにだ。 テーブルA 列名 データ型 列1 text 列2 text 列3 int 列4 int テーブルB 列名 データ型 列1 text 列2 text 列3 text
デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
MySQLのインデックスを学ぶ (1) - 刺身☆ブーメランのはてなダイアリー
実践ハイパフォーマンスMySQL 第2版とLinux-DBシステム構築運用入門を読んで、 MySQL のインデックスについて勉強しなおしている。理解が曖昧だった部分の知識を深められたり、自分の間違いに気づけたりして、とても収穫が多い。 フルテーブルスキャンとフルインデックススキャン Linux-DBシステム構築運用入門 P185 に書いてあるケース。インデックスを利用してても対象レコード数が多いとランダムI/Oが大量に発生して遅くなる。読むべきレコード数が多いのならばフルテーブルスキャンのほうがI/O一回で多くのブロックを読み込めるので速い。 IGNORE INDEX ヒントを与えてパフォーマンスを改善するという例があった。 マルチカラムインデックスと範囲検索 SELECT * FROM users WHERE a = ? AND b >= ? and (c IS NULL OR c >=
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
