DB専門の学習

「B-treeだけがインデックスじゃない」：巨大データを救うBRINインデックスの極意やあ。データベースのパフォーマンスチューニングに頭を悩ませているなら、ちょうどいいタイミングだ。PostgreSQLを使っていると、とりあえず「困ったらB...

巨大なデータと戦うエンジニアの救世主、「BRINインデックス」って何？こんにちは！日々データベースと格闘しているエンジニアです。皆さんは、何億行もあるような巨大なテーブルを扱うとき、検索の遅さに頭を抱えたことはありませんか？「インデックスを...

「重複」をどう防ぐか：PostgreSQLの隠れた宝石、排他制約（Exclusion Constraint）の話PostgreSQLを長年触っていると、「一意制約（UNIQUE）」には飽き飽きしてくるものです。特定のカラムが重複しないように...

「また予約が重複しちゃったよ……」。開発現場で一度は耳にする、あの絶望的なセリフ。会議室の予約、ホテルの空き状況、あるいは期間限定のキャンペーン設定。これらをアプリケーション側のロジックだけで「重複なし」に制御しようとすると、必ずどこかで不...

「予約がダブルブッキングしちゃった！」を防ぐ、PostgreSQLの賢い守護神：排他制約の話こんにちは！データベースの世界へようこそ。普段、会議室の予約システムや、ホテルの宿泊予約サイトを使っているとき、ふとこんなこと考えたことはありません...

JSONB時代の今、あえて「hstore」を語る意味最近のPostgreSQL界隈では、JSONBが完全に市民権を得ていますよね。スキーマレスなデータ構造をリレーショナルな世界に持ち込むならJSONB一択、というのが現在の定石です。でも、ベ...

JSONB全盛の今、あえて「hstore」を語る理由「先輩、今のプロジェクトでスキーマレスなデータを入れたいんですけど、やっぱりJSONB一択ですよね？」最近、後輩からこんな質問をよく受けます。もちろん、PostgreSQLにおいてJSON...

こんにちは！データベースの世界へようこそ。普段、皆さんが「住所録」や「タスク管理アプリ」を作るとき、Excelの表のようにきれいに整ったデータを想像しますよね。「名前」の列があって、「電話番号」の列があって……というアレです。でも、開発を続...

なぜ今さらUUIDなのか？：PostgreSQLにおける「主キーの最適解」を再考するDB設計の初期段階で、誰もが一度は直面する問いがあります。「主キーを何にするか」。かつては連番の `SERIAL` や `BIGSERIAL` が黄金律でし...

なぜ今さら「UUID」なのか？PostgreSQLで主キー設計を考える君へ現場でバリバリとデータベースを触っていると、主キーの設計について一度は悩むよね。「とりあえず `BIGSERIAL` でいいか」と連番のIDに逃げていないかな？もちろ...