GitHub - neilotoole/sq: sq data wranglerYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
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に着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
尾を噛む蛇としての外部キー制約 - 『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」からの続きです。） 公開されているスキーマを見てみる ユーザーがスキーマを変更したり、新規テーブル
データベーステーブル設計の基礎の基礎〜エンティティの抽出・定義から正規化まで - エンジニアHub｜若手Webエンジニアのキャリアを考える！
データベーステーブル設計の基礎の基礎～エンティティの抽出・定義から正規化まで 適切な形でデータベースのテーブルを設計し、運用するには？テーブル設計に必要な初歩を日本MySQLユーザ会副代表の坂井恵さんが丁寧に解説します。 金融系アプリ、ゲーム、人工知能などなど……。どんな種類のシステムを開発する上でも、避けて通れない領域があります。データベースです。データを適切な形式で格納し、取り出す。単純明快ながらも奥深いこの仕組みは、多くのシステムの根幹を支えています。 しかし、適切な形でデータベースのテーブルを設計し、運用するのは簡単なことではありません。「良いテーブル設計」のためには知識と経験が不可欠です。今回は日本MySQLユーザ会の副代表である坂井恵さんに、これからテーブル設計に着手する方に向け、設計に必要な技術と、良い設計を作るための考え方を教えていただきました。 坂井恵（さかい・けい） @
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - drawdb-io/drawdb: Free, simple, and intuitive online database design tool 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