はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録

Data Models: A Comprehensive Guide to Structuring Information for Optimal Insights and Decision-Making In the realm of data management, the use of effective data models plays a pivotal role in organizing and representing information in a structured and meaningful way. Data models serve as the blueprint for databases, facilitating efficient data storage, retrieval, and analysis. This article delves

ユーザごとに特定の機能に対して ON/OFF の設定値を持たせることはよくあると思います。 RDB にそのような設定情報を持たせる場合の選択肢として大きく次の 5 つが考えるんじゃないかと思います。 設定項目ごとにカラムを割り当てる 設定項目ごとにレコードを割り当てる（追記：アンチパターンという意見があるので最後に補足を書きました） 設定項目ごとにテーブルを割り当てる（自分は思い付かなかった） 設定項目ごとに 1 つの整数型カラムの 1 bit を割り当てる 1 つのカラムに JSON 等で全ての設定情報を持たせる データベース理論的には 1, 2, 3 以外の選択肢はない気がしますが、実用上は 4, 5 も良い選択となることがあるので、メリット・デメリットを考えて選択する必要があると思います。 そんなわけで、それぞれの選択肢に関してメリット・デメリットを自分なりに考えてみました。 考慮す

2016年7月27日 Database Lounge Tokyoで話した内容。 タイトルは名ばかりでリカバリとIn-MemoryDBの話が主体Read less

"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に

GitHubのエンジニアがデータベースのスローログから見つけた、LIKE句を使ったクエリーのパフォーマンス問題につながる可能性のある文字列。問題の仕組みと、それを回避するためのスニペット。 先日、例外情報のトラッカーを見回していたら、目を引くスロークエリーログを発見しました。SELECT ... WHERE ... LIKEといったクエリーのLIKE句にたくさんのパーセントが付いているのです。この部分はユーザが入力した部分なのは明らかで、最初私はSQLインジェクションを疑いました。 [3.92 sec] SELECT ... WHERE (profiles.email LIKE '%64%68%6f%6d%65%73@%67%6d%61%69%6c.%63%6f%6d%') LIMIT 10 コードを見てみると、ここで解釈されるメタ文字(%や_や\)のチェックをまったくせずにユーザが指定し

リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを

めっちゃよくまとまっているので、大変助かりました。 blog.mogmet.com t-wada氏の「とりあえず削除フラグはアカン」については、僕も全く同感です。論理削除をしなければならないビジネス上の理由がスッポリ抜け落ちている。「とりあえず削除フラグ立てて何かあれば戻せるようにすればいいンゴ」ってのは論理設計を放棄していると言い換えても良いし、「ユーザーの言葉ではない」という指摘も重要。こちらに書かれています。 ledsun.hatenablog.com じゃ、フラグやめてどーすんのって話。フラグを立てたくて立てる人はおらん(はず)。「削除フラグを追加するとSELECT時に常にWHERE句で削除フラグを引っ掛ける必要があるのでクソ」→「削除日や状態カラムを使おう」では解決にならん。t-wada氏の資料でも解決策で上げられてたけど「×」マークがついてます。下記に変わっても誰も嬉しくないと

互いの前職での先輩後輩である @kenchan と企画した論理削除 Casual Talks #1で、「論理削除しない」という話をしてきました。 話す内容が各話者で面白いほどかぶっていたのでなかなか大変でしたが、普段から言っている「論理削除するな」「削除じゃないからちゃんと機能を設計しましょう」という内容を話してきました。 他の方の話も、かぶっているようで新しい視点もあって、いち参加者としてもたいへん勉強になりました。

4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にした本で、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。

DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計

Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation. For the best experience please use the latest Chrome or Safari browser. Firefox 10 (to be released soon) will also handle it.

来る2月27日、データベースの新書籍を発売させて頂くことになった。タイトルは「理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL」となっている。単に「データベース」と書いてあるが、RDBがメインのテーマの書籍である。 多くの人が未だにRDBを使いこなせていないのではないか。RDBの使い方をマスターするには何が必要なのか。それがここ数年私が追ってきたテーマであり、この書籍を出すことになった動機である。 あまりにも酷いDB設計、あまりにもスパゲティなクエリ、あまりにも希薄なデータモデルへの理解。そういった問題はどこから生み出されるのか。そのひとつの結論としてたどり着いたのが、「そもそもRDBの使い方があまり理解されていないのではないか」ということだった。名著、SQLアンチパターンでは「やってはいけないケース」について学ぶことができるが、その反対のテーマ、つまり本来どの

動画 Tanel Poder’s Hacking Session: How Oracle SQL Plans Are Really Executed – Part 1 Tanel Poder’s Hacking Session: How Oracle SQL Plans Are Really Executed – Part 2 Tanel Poder’s Exadata Snapper Hacking session videos Oracle full table scans, direct path reads, object level checkpoints, ORA-8103s 資料 Oracle Database オラクル・コンサルが語る！ SQLチューニングに必要な考え方 Oracle SQL Plan Execution: How it really works OWI(O

Developers Summit 2022の登壇スライドです。 https://event.shoeisha.jp/devsumi/20220217/session/3647/ 俺のプロダクト開発用語辞典 https://www.youtube.com/channel/UCnUdhofhFN2RotPou4a55_w オーバーエンジニアリングとは？ https://www.youtube.com/watch?v=6XQOSj7rutI オーバーエンジニアリングとは（ブログ版） https://i2key.hateblo.jp/entry/2021/12/25/101957

こんにちは、すっかり秋ですね！@yone098 です。 みなさんDBの設計してますか？ DB設計時のサイズ見積り 以前はてなダイアリーで書いた記事は5年前のものであり、リンクが切れているものがあるので最新版として MySQL, PostgreSQL, Oracle, SQLServer におけるDB設計時のサイズ見積りをまとめ直しました。 URL内のバージョン表記を変えると以前のバージョンの情報になります。 MySQLは、あまり情報に変化は無かったので Excel でマクロなどを作成して自社で自動算出出来るようにするのが良いと思います。 データタイプごとに必要な要求ストレージが決まっているのでレコードサイズが決まり、あとは要件次第で何レコードになるかを予測します。 データタイプごとに必要な記憶容量 テーブルの最大サイズ関連 http://dev.mysql.com/doc/refman/5