なぜステータスが混在するテーブル設計が生まれるのか
はじめに 業務システムのDBを読んでいると、一つのテーブルに複数のステータスカラムが同居しているケースをよく見かけます。 CREATE TABLE orders ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, user_id INT UNSIGNED NOT NULL, order_status TINYINT NOT NULL, -- 1:受付 2:審査中 3:処理中 4:完了 5:停止 payment_status TINYINT NOT NULL DEFAULT 1, -- 1:未請求 2:請求済 3:収納済 4:失敗 external_status TINYINT, -- 外部システムのステータス（1〜4, 9） external_code VARCHAR(2), -- 外部機関ごとにコードが異なる processed_at VARCHAR(8
データモデルのイベントの期間の設計のコツ - そーだいなるらくがき帳
アプリケーションを開発するときに期間を表すデータを扱うことは珍しくない。 例えばイベントの開催時間、タスクの予定時間などである。 実際にイベントの開催をDBに保存する場合によく見るテーブルは以下のようなものだろう。 CREATE TABLE events ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, start_at TIMESTAMP NOT NULL, end_at TIMESTAMP NOT NULL ); このテーブルはCopilotが提案してくれたもので、開始時間と終了時間をそれぞれ start_at と end_at カラムで保存している。 実際にみんなも現場でよく見る設計ではなかろうか。 AIが一発で提案してくるくらいには一般的な設計である。 ただ、期間を一つのテーブルに持たせることは常にベストというわけではないとい
Oracle Master 2019 Bronze～Silver～Gold オススメのルートは？
最初に 本記事は筆者の個人的な経験・主観に基づいた内容を含んでいる。 そのため全てを鵜呑みにせず、ご自身の経験・環境に応じて参考にして頂けると幸いである。 記事の概要 2023年にBronze～Goldまで取得してから未だに思う、これから受験する人に伝えたいことを語る。 尚、筆者は 『Gold』までで『Platinum』は取得していない。 対象者 Oracle Masterを受験したいが、下記のように思っている方々。 データベースに詳しくないけど、通用するのか不安。 Bronzeから始めるべき？ いきなりSilverでも良い？ SilverだけDBAとSQLの２つがあるけど、どうすれば良い？ 必須条件 エンジニア経験は問わないが、SQLに関して入門レベルの知識は必要と考えられる。 ※事前にSELECT文だけでも勉強しておくことをオススメする。 推奨すること Oracle認定資格は高額なため
DB へのアクセスを伴う単体テストの考え方と Go による実践 - Cybozu Inside Out | サイボウズエンジニアのブログ
この記事は、CYBOZU SUMMER BLOG FES '25の記事です。 クラウド基盤本部の新井です。 この記事では、DB へのアクセスを伴う Go の単体テストについての私たちの考え方、そしてそれを実践するために開発・公開したライブラリをご紹介します。 DB のモックとその問題点 DB へのアクセスを伴う Go のプログラムをどのように単体テストしたいとき、最初に思いつくのは go-sqlmock などのツールを使って DB をモックする方法です。 サンプルコードでは、次のようなテストを書いています。 package main import ( "fmt" "testing" "github.com/DATA-DOG/go-sqlmock" ) // a successful case func TestShouldUpdateStats(t *testing.T) { db, mo
MySQL/Postgres におけるトランザクション分離レベルと発生するアノマリーを整理する
読者対象 ANSI 定義の古典的なトランザクション分離レベルとアノマリーは概ね理解している MySQL/Postgres では理論的な部分がどうなっているのかを知りたい 理論面の前提知識 2022-08-19 追記: 社内勉強会向けのスライドを作成しました。先にスライドを見てから，引用文献およびこの記事を読むと理解が深まると思います。 まず ANSI 定義の古典的な定義を聞いたことが無い方は，以下のリンクを参照されたい。 ANSI 定義に対応する解説はこれらのサイト以外にもたくさんあるため，自分にとって読みやすいと感じる情報をあたってほしい。（既に熟知されている方は十分） 次点で読んでいただきたいのが， @kumagi さんの以下の記事。古典的には 4 つの分離レベルと 3 つのアノマリーだけで説明されていたものの，不十分であることが学術的に指摘され，解像度を上げようとする流れが後になって
論理削除 - kawasima
ユーザなどのリソースエンティティのパージするわけではないデータ削除(a.k.a. 論理削除)をどう設計するか、は単純でありながら、イミュータブルデータモデルの基本形を学ぶ良い題材なので、順を追って説明する。 リソースの検討 まずユーザがアクティブなユーザと削除されたユーザで扱いが異なるかどうかを考える。この段階で物理設計としてどうするかを考えると検討ポイントが十分考慮されないことにつながるので注意しよう 。(イミュータブルデータモデル#5e3a5f1da8e5b200009c0499) 扱いが異ならない場合を考えてみよう。 code: (mermaid) classDiagram direction LR class ユーザ { <<Resource>> ユーザID : SERIAL PK 名前 : VARCHAR メールアドレス : VARCHAR ユーザ区分 : ENUMアクティブ/削
関連のモデリング - kawasima
ドメインモデリングにおいて、エンティティ間の関連（リレーションシップ）をどのように表現するかは、システムの保守性や拡張性に大きく影響する重要な設計判断となる。 なぜ関連のモデリングが重要か 関連の設計が不適切だと、以下のような問題が発生する： 不変条件の検証が困難になり、データ整合性が保てない パフォーマンスの問題（N+1問題、過剰なメモリ使用） ドメインロジックの複雑化と保守性の低下 集約境界の破壊によるトランザクション管理の困難 データベースレベルでは、多対多の関連は交差テーブルを用いて表現されるが、ドメインモデルではより多様な表現方法が存在する。それぞれの設計選択は、パフォーマンス、メモリ使用量、コードの複雑性、ドメインロジックの表現力などに異なる影響を与える。 スキーマの例 まず、典型的な多対多リレーションのデータベーススキーマを見てみよう： code:sql -- 学生 CREA
Go の sql.DB がコネクションプールを管理する仕組み
Go の database/sql パッケージ の DB 構造体 は、データベースへのコネクションプールを管理し、かつスレッドセーフ (goroutine セーフと言ったほうが良いのだろうか…?) にそれらの接続を使用できることを保証している。 ドキュメント にも次のように書かれている。 DB is a database handle representing a pool of zero or more underlying connections. It’s safe for concurrent use by multiple goroutines. こちらの基本的な実装内容と、動作を制御するパラメータについて調べてみた。 基礎知識のおさらい database/sql パッケージはデータストアの実装によらない一般的な SQL のインタフェースを提供している。具体的なデータストアへの接
自作RDBMSやろうぜ！（出張版） - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ご無沙汰しています。 ryo_gridです。 Disclamer 本記事は自作DBMSやろうぜ！ のページの 22/05/11 JST 7:45 の時点での内容をQiita記事向けに修正して作成したものです 元コンテンツのライセンスについては以下をご参照ください LICENCE 元コンテンツの方は更新が継続されていますので、よろしければそちらもご覧ください この記事の目的 RDBMS（いわゆるリレーショナルデータベース）というものはプログラミング言語の処理系や、OSなどと同様に、世の中で広く使われているソフトウェアであるにも関わらず、自
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://x.com/matsuu/status/2033117810076045390?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
概観 トランザクションとロック - 用語整理と最初の一歩 -
RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag
https://x.com/t_wada/status/2001842265287987547?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://x.com/backenddevcat/status/2001313124465385659?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://x.com/a_suenami/status/2000957186655314163?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
手を動かしながら学ぶデータモデリング - 論理設計から物理設計まで / Data modeling
https://x.com/tzkb/status/1942847646475120678?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://x.com/kawasima/status/1942850960050774091?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
変化に強いテーブル設計の勘所 / Table design that is resistant to changes
https://x.com/matsuu/status/1891053049596059887?s=12&t=suYC6B2IhN7jv0qU5zDxmQ