データベースを止めずにテーブル設計を変更したい
プラハチャレンジにて、受講生チームから次のような質問がありました。 データベース（RDB）のテーブル設計を変更したい テーブル設計を変更する作業中にアプリケーションからデータベースへのアクセスが発生すると困る メンテナンス期間を設けアプリケーションを一時的に停止することで、データベースへのアクセスを防ぐことはできる データベースを止めることなくテーブル設計を変更する方法はないか この質問に対して、Expand and Contract patternを紹介しました。 この記事では、Expand and Contract patternを用いてテーブル設計を移行する方法を例を交えて紹介します。 ことのおこり プラハチャレンジのデータベース設計の課題の1つに、次のようなものがあります。 「漫画・小説といった書籍を保存してそれらにコメントできるようなサービス」（以下、書籍サービスとします）のデー
RDBの主キー、UUID使った方がいいの？(DDD, CleanArchitecture対応)
結論 お手軽モノリスならAutoIncrementが効率的だしこれでいいよ アプリケーション側で主キーを生成したい場合はLUIDを作る必要があるよ。GUIDで大は小を兼ねよう 主キーでGUIDを使うならULIDよりもUUIDv7がおすすめだよ ただし分散されているエンジンによってはUUIDv4の方が効率的になる場合もあるよ 主キーは原則公開しない方がいいよ UUIDv7やULIDはユニーク性を持ったInstant(timestamp)としても使えるよ 分散されたシステムでは厳密な時系列性を担保することはできないよ、あきらめてロックをかけつつ連番を一か所で生成しよう RDBのPrimary Key(主キー)とは？ MySQL、PostgresQLなどのRDBでは各レコードを識別するために一意な値を必要とします。これをPrimary Key(主キー)と呼びます。別のカラムにUNIQUEなInd
イミュータブルデータモデル - kawasima
はじめに CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。 手順 Step1. エンティティを抽出する まずエンティティを抽出するところから始める。 5W1Hがエンティティの候補 従業員,患者,プレイヤー,顧客,生徒,... 製品,サービス,コース,曲,... 時間,日付,月,年,年度,... 送付先,URL,IPアドレス,... 注文,返品,入金,出金,取引,
尾を噛む蛇としての外部キー制約 - 『SQLアンチパターン』のキーレスエントリ（外部キー嫌い）を考察する
この例では「担当カウンセラーID」「利用者ID」「相談種別ID」が外部キーになります。それらのカラムに入力できるのはそれぞれ参照先の親テーブルに存在する主キーのIDか、もしくはNULLです。 設定可能なreference_optionオプション reference_optionとは、外部キーとして参照されている親テーブル側のレコードを削除・更新したときに、参照している子テーブルの外部キーをどうするか？ というオプションです。利用するRDBMSによりますが、だいたいのRDBMSで以下３種類の設定が可能になります。（MySQLだとこちらのページの参照アクションを参照。） CASCADE 親テーブルの削除・更新を行ったのち、その更新内容を子テーブルにも反映させます。 SET NULL 親テーブルの削除・更新を行ったのち、子テーブルの外部キーをNULLで埋めます。 RESTRICT(NO ACTI
Railsで秒間1000コミットを捌くにはどうすればいいのか (Kaigi on Railsのフリースペースより) - joker1007’s diary
先日のKaigi on Rails中の雑談として @ima1zumi さんから、RDBに対して秒間1000コミットぐらいで処理が詰まってる場合ってどうするのが良いのか、という質問を受けまして、雑談の中で色々答えてたんですが、せっかくだから記事にまとめておこうと思います。 ちょっとしたKaigi Effectって感じですね。 今回のKaigi on Railsのトークの中では、 数十億のレコードを持つ5年目サービスの設計と障害解決 by KNR - Kaigi on Rails 2023 の話なんかは割と関連がありますね。ユーザーの行動履歴というのは、ユーザー数 * N * タイムスパンで増えていくレコードなので、書き込みとデータ量が爆発しがちです。トランザクションで堅牢に処理しなければいけないケースもそこまで多くないので、RDBだと書き込みに対する処理が過剰なケースが多い。実際のところこの
史上最強のデータベース、SurrealDB - Qiita
SurrealDBというRust製データベースを知ったので紹介します。このデータベースはすごいです。リレーショナル、ドキュメント、グラフ、あらゆる種類のデータ構造を扱うことができ、かつインメモリ、単一ノード、分散環境、全てで動かすことができます。さらにHTTPやWebSocketによるアクセスと柔軟なユーザ認証、認可機能とがDB本体に内包されており、ブラウザから直に接続するWebDBとしても使えます。とにかくなんでもできる夢のデータベースといった感じです。 特徴 機能を挙げていたら多くなりすぎたので、特に面白い部分を挙げます。 配列やオブジェクトをネストした複雑なデータ構造を持てるのに、レコードリンクという機能によりリレーションに対応していてしかもSQLやMongoDBより簡潔にクエリが書ける。 スキーマレスで各レコードには任意のフィールドを持てるが、必要ならスキーマを定義することもできる
簡単関係照会言語 Erq で快適なデータベース分析生活を送る - Ryusei’s Notes (a.k.a. M59のブログ)
Erq（アーク）は、SQLの代わりにアドホックなデータ分析に用いることを主目的とした、新しいデータベース言語です。リレーショナルデータベースは便利ですが、アドホックなデータ分析を行う上で、SQLの文法は面倒なものです。Erqは、SQLのセマンティクスは極力そのままに異なる文法を採用することで、簡単にクエリを書けるようになっています。 SQLクエリの実例 私はSQLiteデータベースに漢字の文字情報を入れて、複雑な検索や分析ができるようにしているのですが、実際にそのデータベースを使ったクエリ例を見てみましょう。使っているMojidataデータベースは、次のリポジトリからビルドできます。 GitHub - mandel59/mojidata: Character Database for CJKV Text Processing まず、漢字の読みを集めたmji_readingテーブルの内容を全
【firestoreアンチパターン】RDB思考でfirestoreを使うと危険な4つのケースと対策 - Qiita
こんにちは。virapture株式会社のもぐめっとです。 最近ユニクロで友達とオソロのメタモンTシャツ買いました。カワイイです。 本日はfirestore使ってて辛いよーという声をよく聞いたので、そのままfirestore使っていると危険な理由と対策など4つのアンチパターンとして紹介しようと思います。 1. Join Lover: データをjoinする 目的 RDBではよくあるテーブル同士を結合してデータを取り出すJoin。 firestoreでjoinを用いたいケースというのは特定のドキュメントのデータだけでは表示する要素が足りないので別のドキュメントから取得してなんとかするみたいな感じになると思います。 しかし、firestoreのプロもおっしゃってますが、firestoreへのjoin追加は望みが薄いと思われます。 RDBで重くなってる要因も外部結合や副問い合わせとかガンガン使って重
みずほ銀行システム障害の原因にさらなる疑問、気になる「本件メモリ常駐」
「やはりそうだったのか」――。みずほ銀行で発生した一連のシステム障害について、「システム障害特別調査委員会」がまとめた調査報告書（2021年6月15日）を読み終えて、残念な気持ちになった。 報告書では発生した4件の障害について事実概要や原因を説明している。特に影響が大きかったのは、システムのキャパシティー不足に起因する、2021年2月28日に発生したデータ更新作業の失敗だ。特定条件の口座をみずほe-口座に一括切り替えする処理で、前日の27日は全体で60万件のデータを問題なく処理したが、28日は同70万件だったためにメモリー不足に陥った。この経緯を踏まえ、筆者は3月に執筆した記事で「前日の運用に、障害を回避できるヒントがあったのではないか」と指摘した。 関連記事： みずほ銀行システム障害の原因に疑問、気になる「前日の運用」 指摘した内容は2つある。1つは、前日のメモリー使用率もかなり高かった
GitHub - gluesql/gluesql: GlueSQL is quite sticky. It attaches to anywhere.
GlueSQL is a Rust library for SQL databases that includes a parser (sqlparser-rs), an execution layer, and a variety of storage options, both persistent and non-persistent, all in one package. It is a versatile tool for developers, supporting both SQL and its own query builder (AST Builder). GlueSQL can handle structured and unstructured data, making it suitable for a wide range of use cases. It i
アカウント削除機能に意味はない - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Webサービスでアカウント削除機能を要求するユーザの話はよく聞くわけですが、これには残念ながら全く意味が無いと、1Webエンジニアであるぼくは思っているのですが、その理由をだらだらと書いてみようと思います。非エンジニアでも分かるように書いたつもりですが、作者が特にそういう能力に秀でているわけでもないので難しいかもしれません。 技術的な問題 現代の多くのWebサービスはデータの保存をRDB(SQL)に依存しています。これには色々特徴があるわけですが、実際の実装を想定して説明していきましょう。 ユーザがいます。ここではUserというTabl
知られざる「マルチテナントアーキテクチャ」（3）～スキーマとメタデータの謎 － Publickey
セールスフォースが採用しているマルチテナントアーキテクチャでは、すべてのユーザーが同一データベース、同一スキーマを共有しています。 では、個別に入力項目を増やすようなスキーマの変更を伴うアプリケーションのカスタマイズや、新たなテーブルを作成してそこに独自データを保存するようなアプリケーションの新規作成はできないのか？ といえば、そんなことはなく、セールスフォースが提供するプラットフォームの上で、自由に項目の追加や新しいテーブルの作成が可能です。 全ユーザーでスキーマを共有しながら、しかし個別のカスタマイズを許容する。この一見矛盾する要件を、セールスフォースはどのように実現しているのでしょうか？ （本エントリは「知られざる『マルチテナントアーキテクチャ』（2）～スケーラビリティのカギは組織ID」からの続きです。） 公開されているスキーマを見てみる ユーザーがスキーマを変更したり、新規テーブル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - neilotoole/sq: sq data wrangler
GitHub - drawdb-io/drawdb: Free, simple, and intuitive online database diagram editor and SQL generator.
データベースの仕組み(アーキテクチャ)をざっくり理解する
GitHub - BardurArantsson/peregrin: Haskell database migration support for use in other libraries
GitHub - rqlite/rqlite: The lightweight, distributed relational database built on SQLite.
DB Fiddle - SQL Database Playground
How Does a Database Work?
Back to the Future with Relational NoSQL