データベースの正規化(第1〜第3正規形) - Wiz テックブログ
こんにちは！バックエンドエンジニアの小室です。 先日、4月から入社予定の方に向け「データベース設計」について研修を行いました。 その中でもメイントピックであった「正規化」について改めてまとめてみました。 さっそくですが、データベースにおける正規化とは、 データベースで保持するデータの冗長性を排除し、 一貫性と効率性を確保するためのデータ形式へ変換することを指します。 一般的に第3正規形までで十分とされているため第3正規形までを取り上げます。 第1正規形 テーブルの行と列が交わる1つマスを「セル」と呼ぶことにします。 第1正規形の定義は「1つのセルには1つの値しか含まれない」です。 社員テーブル このように1つのセルに1つの値が含まれているとき、この値を「スカラ値」と言います。 社員テーブル(非正規形) 上のようなテーブルがあった場合、1人の社員は複数の子を養っているので、このように表現した
外部キー制約でデッドロックに引っかかった話
今回は仕事で直面したデッドロックのケースについて話したいと思います。 今回ハマったケース 今回ハマったケースは、複数プロダクトが共有するデータベースにあるデータを単体プロダクト専用のデータベースに持ち帰る開発を行っていたときでした。かなり簡略化しておりますが現状と分離後の理想型は下記の通りです。 現状 担当プロダクトと別プロダクトは同じ従業員データを参照している 従業員データの中には、担当プロダクト専用のカラムもあれば、別プロダクト専用の項目もある マイクロサービスがもつマスタ従業員データと旧従業員データがそれぞれ持つ名前カラムは同期している 理想系 担当プロダクトは新しい専用の従業員データをもち、専用のカラムはそのテーブルにもつ マイクロサービスがもつマスタ従業員データと各プロダクトの従業員データの名前カラムは同期させる この対応を段階的に進めている途中で、 担当プロダクトによる旧従業員
ドキュメントDBかリレーショナルDBどっち使う？ - Qiita
はじめに ドキュメントデータベースかリレーショナルデータベース、どちらを選ぶか。 この選択で、アプリケーションのパフォーマンス、コスト、コードの可読性など幅広い影響が出るため、慎重な判断が必要です。この記事では、自分が思う「考慮すべきポイント」を解説したいと思います。 考慮すべきポイント 1. どのデータモデルがアプリケーションコードに最適か スキーマ制約を課さずに、データレコードをドキュメント（つまりJSONオブジェクト）として保存すべきか？それともスキーマを正規化してデータをいくつかのテーブルに分けるべきか？ このような判断をするために、開発しているアプリケーションのモデルの関係性（例: UserとTaskの関係が1:N）と、一度に読み込むデータの種類を見た方がいいです。 ドキュメントDBがおすすめの時 アプリケーションのデータは、以下のような木構造で表現できますか？普段そのデータを一
外部キー制約が一切ないと何に困るのか？
こんにちは。株式会社プラハCEOの松原です 注目を集めつつあるMySQLプラットフォームのPlanetScaleですが、外部キー制約が効かないという一見致命的に見える仕様について調べていたところ、こちらのDiscussionで興味深い回答が開発者から寄せられていたので日本語でまとめ直してみようと思いました。 外部キー制約がなくてもそれほど困らない理由 今回の話はParentテーブル(id)とChildテーブル(id,parent_id)を前提に考えていきます そもそも外部キー制約は何に役立つのか 今回のDiscussionでは質問者から「外部キー制約がないとこういう時に困るよ！」と質問が寄せられています： 外部キー制約がないと参照先のデータが存在していることを保証できない！ 外部キー制約がないとデータの重複を回避できない！ それぞれの質問に対して回答者の回答は以下の通りです： 外部制約がな
WEB+DB PRESS Vol.122に特集「Rustで実装！作って学ぶRDBMSのしくみ」を書いた - Write and Run
カラム命名規則 - Qiita
データベースを遅くするための８つの方法
Home | DBML
Intro DBML (Database Markup Language) is an open-source DSL language designed to define and document database schemas and structures. It is designed to be simple, consistent and highly-readable. It also comes with command-line tool and open-source module to help you convert between DBML and SQL. Table users { id integer username varchar role varchar created_at timestamp } Table posts { id integer
ダンプとは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
本当にあったやらかしDB設計①【R無しRDB】 - Qiita
どうも、IT業界は4年目だけど開発はあんまりやったことがなかった人です 独学でDBとアプリ周りを勉強して最近開発現場へと行くことになったのですが、僕でもわかるようなやばいような事がかなりゴロゴロあって唖然とする毎日です(運が良いのか悪いのか…) 今日はそんな中の一つを紹介したいと思います これには本当にびっくりしました どういうことかというと、外部キーをひとつも使ってなかったのです 分析系DBなのかと思いきや調べたり聞いたりして確認したところがっつり処理系、しかもコアな部分…ｗ データの不整合を許せない部分なのに外部キーを全く使っていないという、アンチパターンというか呆れパターンというか… 何が悪いの？？ そう、まずはここから説明していきます 同じことを繰り返さないようにするための記事なので、ただバカにするだけだと意味ないですからね 1980年代～1990年代くらいに過激な生き残りをかけた
本当にあったやらかしDB設計シリーズ一覧 - Qiita
本当にあったやらかしDB設計シリーズをまとめてみました SQLアンチパターンで書かれているほど高尚な問題ではなく、もっと初歩的な、でもありがちな問題を取り上げています 初心者を脱出したと思っている人に是非読んでもらい、正しく設計してもらうことを目的としています もしここに載っていないパターンを経験したことのある方がいたら是非教えてください 本当にあったやらかしDB設計①【R無しRDB】 本当にあったやらかしDB設計②【囚人番号テーブル】 本当にあったやらかしDB設計③【ロジカルクエリー】 本当にあったやらかしDB設計④【テストチューニング】 本当にあったやらかしDB設計⑤【第三正規化病】 本当にあったやらかしDB設計⑥【見えない削除フラグ】 本当にあったやらかしDB設計⑦【ステートフルDB】 本当にあったやらかしDB設計⑧【ファンクションDB】 本当にあったやらかしDB設計⑨【文字列日付】
データベース設計の際に気をつけていること - 食べチョク開発者ブログ
27. 論理削除とは何か？どのような解法があるのか？ w/ twada | fukabori.fm
話したネタ 論理削除とはそもそも何か？ 物理削除とは？ なぜ、論理削除が生まれてくるのか？ SQLアンチパターン 幻の第26章「とりあえず削除フラグ」 理由1: 心理的なハードルの高さ、怖さがある 理由2: 削除したデータを検索対象に入れたい場合がある 理由3: ログとしての用途 理由4: 誤操作をすぐに戻したい アンチパターンとは何か？ なぜ、論理削除はアンチパターンとして捉えられるのか？ 全てのSQL文のWHERE句に削除フラグが必ず入る LIMIT 1などが蔓延していく 論理削除に気づくきっかけは何か？ テーブル設計や、規約から気づく 論理削除というアンチパターンをどのように解いていくか？ 論理削除という概念は世の中にまずなく、お客様は論理削除という言葉を使っていない 要件をどのように設計すればいいのか？ ORMの論理削除プラグインはあまり良くない 状態遷移として捉える方法 Soft
論理削除が云々について - mike-neckのブログ
論理削除フラグという名の死亡フラグ - @ledsun blog
RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita 論理削除が云々について - mike-neckのブログ Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か 流行っているので乗っかります。 結論 「データ制約の強力さと集合としての表現力を捨てながら、Relational Databaseを使うのはなぜか？」 論理削除フラグのデメリット 大体三つあると考えています。 ユーザーの言葉でない データ制約の弱さ 集合として認識できない ユーザーの言葉でない 私の経験上は、ユーザーから「論理削除」という言葉を聞いたことがありません。 次のような要件は、聞いたことがあります 社員が退職（・転属）する （売掛金の回収を諦めて）売上を打ち消す 「お知らせメッセージ」を公開日がくるまで非表示にする 既読メッセージを表示しない 保存期間が過ぎたアンケート結果をオペレ
#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
論理削除の前に別テーブルに切り出せるかどうかを考えよう - Life is Really Short, Have Your Life!!
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
削除フラグのはなし
InfoQ: データの削除は非推奨
