アプリケーションを開発するときに期間を表すデータを扱うことは珍しくない。 例えばイベントの開催時間、タスクの予定時間などである。 実際にイベントの開催を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が一発で提案してくるくらいには一般的な設計である。 ただ、期間を一つのテーブルに持たせることは常にベストというわけではないとい

この記事は hacomono Advent Calendar 2025 の12日目の記事です。 基盤本部で今後のhacomonoのアーキテクチャ設計をしている @bootjp と申します。 今年はマイクロサービス化に向けての社内共通のイベントバスの設計や基盤周りの設計/実装を行っていました。 以前にはこのような記事を書き、分散システムや分散データベース、分散ストレージなどが大好きです。 「Goで作って理解するRaftベースRedis互換KVS」という同人誌も書いています。 もし興味のある方はお手にとってみてください。 はじめに 今回は「クラウドネイティブデータベース」と言われる、昨今のデータベースにおけるコンピューティングとストレージの分離について、どのような動機でこの構成になったのか、利用者としてどのようなメリットがあるのか、そしてトレードオフは何かということについて記事を書かせていただ

こちらの記事はReact Tokyo ミートアップ #8にて発表させていただいた内容をより深堀りした記事となっています。 登壇資料はこちらです。 TanStack DB ~状態管理の新しい考え方~ TanStack DBとは TanStack DBは、フロントエンドに 永続化層（DB） を設け、コンポーネントから直接クエリできる仕組みを提供します。 従来は、バックエンドのDBを正とし、フロントエンドはそれを定期的に問い合わせる形が一般的でした。 TanStack DBはこれを逆転させ、フロントエンドがデータの主導権を持つ 形にします。 つまり「DBをフロントエンドに持ってきた」感覚で使えるのが魅力です。 TanStack DBは何が嬉しいのか 楽観的更新の自動化 同じTanStackシリーズのTanStack QueryはデフォルトではUIの楽観的更新をしません。 つまり、失敗することを前

Web上のコンシューマサービスにおいて、会員の契約プランによって出来ることが異なるものを考える。 ゴールドプラン: 会員限定スペシャルコンテンツが見れる、ポイント倍率5倍 シルバープラン: ポイント倍率2倍 ブロンズプラン 契約は月更新サブスクリプションを想定する。 このような場合、まず考えるべきは、セールス・マーケティングの世界(プランや契約)と、どのサービスが利用できるかの世界(権限)を切り離すことである。プランは短期的な売り上げをあげるために、新プランや使える機能の細かな調整が入ることが想定される。その度にプログラム修正が入っては大変だし、トラブルの元なので、その会員がどの機能を使えるかの制御にはプランを使わないように設計する。 このマーケと権限制御の分離ができていれば、「ゴールドプランのサービスがお試しで使えます！」などのキャンペーンも、アプリケーションとしては会員の権限(会員ラン

ユーザなどのリソースエンティティのパージするわけではないデータ削除(a.k.a. 論理削除)をどう設計するか、は単純でありながら、イミュータブルデータモデルの基本形を学ぶ良い題材なので、順を追って説明する。 リソースの検討 まずユーザがアクティブなユーザと削除されたユーザで扱いが異なるかどうかを考える。この段階で物理設計としてどうするかを考えると検討ポイントが十分考慮されないことにつながるので注意しよう 。(イミュータブルデータモデル#5e3a5f1da8e5b200009c0499) 扱いが異ならない場合を考えてみよう。 code: (mermaid) classDiagram direction LR class ユーザ { <<Resource>> ユーザID : SERIAL PK 名前 : VARCHAR メールアドレス : VARCHAR ユーザ区分 : ENUMアクティブ/削

ドメインモデリングにおいて、エンティティ間の関連（リレーションシップ）をどのように表現するかは、システムの保守性や拡張性に大きく影響する重要な設計判断となる。 なぜ関連のモデリングが重要か 関連の設計が不適切だと、以下のような問題が発生する： 不変条件の検証が困難になり、データ整合性が保てない パフォーマンスの問題（N+1問題、過剰なメモリ使用） ドメインロジックの複雑化と保守性の低下 集約境界の破壊によるトランザクション管理の困難 データベースレベルでは、多対多の関連は交差テーブルを用いて表現されるが、ドメインモデルではより多様な表現方法が存在する。それぞれの設計選択は、パフォーマンス、メモリ使用量、コードの複雑性、ドメインロジックの表現力などに異なる影響を与える。 スキーマの例 まず、典型的な多対多リレーションのデータベーススキーマを見てみよう： code:sql -- 学生 CREA

自分はDBをモックしてテストを行うのが嫌いですが、もし実際のDBを利用し並列実行する場合にポートやtruncate周りの問題が発生します。 今回は、それを解決するためにTestcontainersとVitestを利用したコードで解決します。 Testcontiners Docker社が買収したTestcontainersは、Dockerコンテナをテストで利用しやすくするライブラリです。 開発時にdocker composeを利用している人が多いと思うので、そこで利用しているcompose.yamlの定義をまんまテストで再利用できる点も便利かなと思います。 Testcontainers Testcontainers is an opensource library for providing lightweight, throwaway instances of common dat...

はじめに Googleカレンダーのような時間枠を扱うシステムを設計する際、開始・終了時刻を管理するロジックは容易ではない。 しかし、PostgreSQLには 範囲型 があり、この機能を活用することで、開始時刻（begin_at）と終了時刻（end_at）を1つのカラムで扱えるようになる。 そこで本稿では、範囲型を用いた設計と、その利点を紹介する。 時間枠を扱う難しさ まず前提として時間枠の扱いがなぜ難しいかを紹介する。 ソフトウェアデザインでやっている連載、実戦データベースリファクタリングの 【12】厄介な時間枠に向き合う でも紹介したが、時間の範囲を比較するときが難しい。 範囲の重なりには以下の種類がある。 包含：範囲Aが範囲Bを完全に含む 重複：範囲Aと範囲Bに共通点がある 隣接：範囲Aと範囲Bが隣り合う 時間枠の扱いはSQLに限らず、プログラミングの題材として難易度が高い。 特に重複

例えば次のようなテーブルがあったとする。 -- PostgreSQL CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); -- MySQL CREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, data TEXT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First

近年のデータベースの新潮流にNewSQLと呼ばれる一群のデータベース製品群の登場がある。そのコンセプトを一言でいうと、RDBとNoSQLのいいとこどりである。SQLインタフェースと強いデータ一貫性（ACID）というRDBの利点と水平方向のスケーラビリティというNoSQLの長所を兼ね備えた夢のようなデータベースである。下図に見られるように、RDBとNoSQLが鋭いトレードオフを発生させていたのに対して、NewSQLではそれが解消されているのが分かる。 RDB vs NoSQL vs NewSQL本当にそのような夢の実現に成功しているか、というのはまだ議論が続いているが（クエリのスループットを出すためにレイテンシを犠牲にしているので本当にトレードオフを解消はしていない、などの問題が指摘されている）、商用でも利用可能な製品としてGoogle Spanner、TiDB、YugabyteDB、Coc

ランキング参加中プログラミング はじめに この記事では、Immutable Data Modelと呼ばれる設計手法をもとに、リレーショナル・データベースにおける、テーブル設計の話を書いています。また、今回の実践で利用する、別の考え方の背景を理解するために、Out of the tar pitという小論文の内容にも言及します。 「状態とは何か？」というややこしい話がたくさん出てきますし、データベースのテーブル設計についての話であることから、たくさんのSQLが出てきます。なので、データモデリングとか状態管理とか、特にSQLとかに興味がない人には面白くないと思います。 そのあたりに興味ある方は、読んでみて欲しいです。 Immutable Data Modelを、実際のアプリケーションで使うデータベースに採用するにあたり、どういう考え方で、どのようにテーブルを構成したか、自分なりの経験を書いていま

バフェット・コードは日・米の上場企業の財務分析・ファンダメンタル分析を、効率的に行えるツールです。株価・財務情報・指標など、必要な情報はすべてここに集結しています。もう煩わしい情報集めにはサヨナラを。企業分析をもっと迅速・カンタンに。

はじめまして。そーだい（@soudai1025）です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化

※2020年6月に公開された記事です。 日本PostgreSQLユーザ会の理事を務める合同会社Have Fun Techを起業した曽根壮大（@soudai1025）と申します。元株式会社オミカレ副社長兼CTOです。直近では、『失敗から学ぶ RDBの正しい歩き方』を執筆しました。 今回はデータベースをテーマとして、魅力やMySQLとPostgreSQLの違い、アンチパターンの見極めなどの基礎知識に加え、勉強法などもご紹介します。 RDB関連の求人検索はこちら データベースを学ぶ魅力をエンジニア目線で考察 1.知識の費用対効果が高い エンジニアがデータベースを学ぶ利点という観点から言うと、データベースの特徴は寿命が長いことと私は考えています。 Webアプリケーションの界隈では1年単位でバージョンアップしたり流行っている言語が変わってしまうことがザラにありますが、データベースは10年、20年とい

IDEs AppCode CLion DataGrip DataSpell Fleet GoLand IntelliJ IDEA PhpStorm PyCharm RustRover Rider RubyMine WebStorm Plugins & Services Big Data Tools Code With Me Quality Assurance JetBrains Platform Scala Toolbox App Writerside JetBrains AI Team Tools Datalore Space TeamCity Upsource YouTrack Hub Qodana .NET & Visual Studio .NET Tools ReSharper C++ Languages & Frameworks Kotlin Ktor MPS Amper Edu

PlanetScaleとは PlanetScaleはMySQLのマネージドサービスです。 内部の実装には元々YouTubeのために開発されたMySQLのクラスタリングシステムであるVitessが使用されています。 Vitessの開発に携わってらっしゃるSugu SougoumaraneさんがCTOとして在籍しており、スケーラブルなデータベースを構築するためのサービスとなっています。 すでにSlack, Square, GitHubなどの企業で採用されているそうです。 この記事ではPlanetScaleのどういった点が優れているのか、これまでMySQLが抱えていた問題点をどのように解決しているのかといったことをまとめます。 その中でタイトルにもつけましたが、なぜ外部キー制約をサポートしていないのかといった点も交えて説明します。 これまでのMySQLの問題点 大量のレコードが存在するテーブルの

音声概要 はじめに CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。 手順 Step1. エンティティを抽出する まずエンティティを抽出するところから始める。 5W1Hがエンティティの候補 従業員,患者,プレイヤー,顧客,生徒,... 製品,サービス,コース,曲,... 時間,日付,月,年,年度,... 送付先,URL,IPアドレス,... 注文,返品,入金,出

軽量な時系列データベースエンジンをスクラッチで開発する機会があったので、どのように実装したのかを必要知識の解説を交えながらまとめていきます。 実装はGo言語によるものですが、本記事のほとんどは言語非依存な内容となっています。 モチベーション 筆者は時系列データを扱うツールをいくつか開発しています。その中の一つであるAliは負荷テスト用のcliツールで、メトリクスをクライアント側でリアルタイム描画できるのが特徴です。リクエスト毎にレイテンシーなどの計測結果が際限なく書き込まれてくる中、同時に一定のクエリパフォーマンスが求められます。 これは言ってしまえば、簡易クエリ機能付きのpush型モニタリングシステムを単一ホストで実現するようなものです。 以前までの実装ではヒープ上の可変長配列にデータポイントを追加していくだけだったので、当然ながら時間の経過とともにメモリ使用量が増加していく問題を抱えて

はじめに ある新サービスの環境構築中、Azure DevOpsのPipelineからApp Serviceをデプロイしたところ、 Azure SQL Databaseへの接続で Login failed for user '{ユーザー ID}'. というエラーが発生し、調査に時間を要しました。 結果として、パスワード間違いのログイン試行を繰り返したためにSQL DatabaseにApp ServiceのIPアドレスがBANされていたのですが、調査の流れについてまとめておきます。 状況 SQL Databaseの設定状況 開発期間等の関係から、ID/Passwordを使ったSQL Server認証を利用（いずれAzure Active Directory認証を利用したい・・・） [Azureサービスを許可する]をオン、追加で開発するオフィスとVPN回線のIPアドレスを許可 エラーの発生条件

「オフラインファースト」なモバイアプリを実現する「MongoDB Realm Sync」が正式版に。モバイル用DBがクラウド上のMongoDB Atlasとデータ同期 MongoDBは、モバイルアプリ用のデータベース「Realm Mobile Database」とクラウド上のバックエンドデータベース「MongoDB Atlas」のデータ同期を行う機能を備える「MongoDB Realm Sync」が正式サービスになったことを発表しました。 ICYMI: MongoDB Realm Sync is now GA! Use it to seamlessly sync data between mobile devices, users, and MongoDB Atlas on the backend, whenever devices are online. https://t.co/DBV