DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
無印良品の会社の情報系システムはbashで作っているそうだ - nobusueの日記
無印良品ブランドを展開している良品計画では、情報系システムの内製化を進めて効果をあげているそうです。 独自の手法で10倍速開発 7割主義で変化対応力を高める ポイントの一つとして、スクリプト言語を活用した独自の開発手法を採用していることがあるそうです。スクリプト言語の採用そのものは珍しくないと思うのですが、ユニークなのはbashを使っていることです。 データを検索したり業務に合わせてデータを加工するビジネスロジックや、データ処理の一貫性を保ったりデータを二重化するデータ管理ロジックは、すべて「Bash」と呼ぶスクリプト言語で記述する。しかもデータベース管理ソフトを使わず、データはすべてテキストファイルで管理する。「ミドルウエアのオーバーヘッドがない分、処理も速い。ごく普通のパソコンで動作させても、25万件の商品データなら2秒程度で全件検索できる」と山崎課長は胸を張る。 実際のコーディングイ
Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ - Qiita
まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど
なんちゃって個人情報
なんちゃって個人情報は「Generator of the Year」にて【便利賞】を受賞いたしました！！ 投票して下さったみなさま、本当にありがとうございました。 今後もどんどん使ってやって下さい。 プログラム等に使えるかもしれない個人情報のテスト用データを作成できます。特に説明が必要なものでもないので、とりあえずやってみていただければわかると思います。 念の為書いておきますが、生成した偽個人情報により発生したいかなる損害も当方は一切関知しません。たまたま名前が実在の人物と同姓同名になってしまうかもしれませんし、特に電話番号や携帯については実際に使われている番号と重なることがありますから、扱いには十分注意して下さい。 何かご要望とかありましたらお気軽にブログまでコメント下さい。 HTML シンプルなHTMLのテーブルで出力します。 XML ルートを<records>、各レコードを<reco
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Mobage を支える Ruby の技術 ~ 複数DB編 ~
