こんにちは、Development Teamの三宅です。 先日、社内（AI事業本部内）でSQL研修の講師を担当したので、今回はその内容について簡単に共有したいと思います。 はじめに 例年、AI事業本部では、新卒エンジニアの育成のためにソフトウェアエンジニア研修を行っております。今年はフルリモートでの実施となりました。研修期間は2週間ほどで、内容は前半が講義、後半が実践（チーム開発）でした。私が担当したのは、講義パートの一部であるSQL研修です。SQLやRDBにあまり慣れていない人でも、できるだけ体系的な学びが得られるようにすることを目標に、様々な資料をまとめて提供する方針で準備しました。結果的には、ハンズオン込みで4時間ほどのやや長い講義となりましたが、勉強になったという声も頂けたのでやって良かったと思っています。 研修資料 研修内容 SQL研修の内容は、基本的には大学のデータベース講義で
データベースを遅くするための８つの方法
はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが１時間越えに化けることもザラにあるので原
皆さんこんにちは、エンジニアの西尾です。 新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。 データベースはシステムの土台です。 土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。 また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。 データベース設計には”これだ！”という正解はないと思っています。 サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。 その他もろもろの背景により、データベース設計の仕方も変わってきます。 このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。 アンチパターンと呼ばれるものも時と場合によっては正解になります。
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
はじめに タイトルのとおり、RDBのデータモデリング・テーブル設計を行う際に参考にしている考え方と関連資料をまとめました。 P.S. なんと本記事内でいくつか参考として挙げさせてもらっている増田さん・かとじゅんさん・奥野さん・そーだいさんからコメントいただくことができました。 本当にありがとうございます。 前提 RDBを採用するのは事実を無駄なく正しく記録するため 正規化、トランザクション、制約とデータ整合性 基本的には始めに理想として集合論・リレーショナルモデルに基づいて正規化を考え(論理設計)、パフォーマンスなどの現実問題に対して折り合いをつけていく(物理設計) 制約を最大限利用する cf: ↑P91〜 ↑P.29,41 ↑P56〜 ↑5章 ↑P347～ 情報とデータ データ：単なる事実の値→これを永続化して蓄えるものがRDB 情報：データから生み出される意味や目的のあるもの→RDBか
NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。
はじめに CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。 手順 Step1. エンティティを抽出する まずエンティティを抽出するところから始める。 5W1Hがエンティティの候補 従業員,患者,プレイヤー,顧客,生徒,... 製品,サービス,コース,曲,... 時間,日付,月,年,年度,... 送付先,URL,IPアドレス,... 注文,返品,入金,出金,取引,
本当にあったやらかしDB設計シリーズをまとめてみました SQLアンチパターンで書かれているほど高尚な問題ではなく、もっと初歩的な、でもありがちな問題を取り上げています 初心者を脱出したと思っている人に是非読んでもらい、正しく設計してもらうことを目的としています もしここに載っていないパターンを経験したことのある方がいたら是非教えてください 本当にあったやらかしDB設計①【R無しRDB】 本当にあったやらかしDB設計②【囚人番号テーブル】 本当にあったやらかしDB設計③【ロジカルクエリー】 本当にあったやらかしDB設計④【テストチューニング】 本当にあったやらかしDB設計⑤【第三正規化病】 本当にあったやらかしDB設計⑥【見えない削除フラグ】 本当にあったやらかしDB設計⑦【ステートフルDB】 本当にあったやらかしDB設計⑧【ファンクションDB】 本当にあったやらかしDB設計⑨【文字列日付】
概要 名著SQLアンチパターンを読み終えたので、それの復習のために悍ましいデータベースを作ろうと思った。 まず前半では、SQLアンチパターンを意図的に盛り込み、目も当てられない酷い設計をします。 そのあとリファクタリングを行なったER図に書き直していきます。 なお、真面目に書くと参考書の丸写しになってしまうので、この記事は アンチパターンもりもりのER図を見て嫌悪感を学習し、設計に役立てようという趣向のもと、詳しい説明は省きます。 とても良い本なので読んでください。 想定するシステムの概要と状況 目的において適切かはわかりませんが、とりあえず考えることの多い”お金”を扱うシステムを想定してみます。 私はブラックジョークが好きなので、今回は「ちょっと怖い金融屋さんが使う債務者管理システム」のER図を設計してみようと思います。 ざっくりした要件 債務者を登録でき、プロフィールを入力できる。 債
Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - Agile Journey
はじめまして。そーだい（@soudai1025）です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化
※2020年6月に公開された記事です。 日本PostgreSQLユーザ会の理事を務める合同会社Have Fun Techを起業した曽根壮大（@soudai1025）と申します。元株式会社オミカレ副社長兼CTOです。直近では、『失敗から学ぶ RDBの正しい歩き方』を執筆しました。 今回はデータベースをテーマとして、魅力やMySQLとPostgreSQLの違い、アンチパターンの見極めなどの基礎知識に加え、勉強法などもご紹介します。 RDB関連の求人検索はこちら データベースを学ぶ魅力をエンジニア目線で考察 1.知識の費用対効果が高い エンジニアがデータベースを学ぶ利点という観点から言うと、データベースの特徴は寿命が長いことと私は考えています。 Webアプリケーションの界隈では1年単位でバージョンアップしたり流行っている言語が変わってしまうことがザラにありますが、データベースは10年、20年とい
Database schema templates Collection of real world database schemas from open-source packages and real-world apps that you can use as inspiration when architecting your app.
基本から学ぶ テーブル設計 超入門！ 〜データモデリングとテーブル設計の基本を学ぼう〜 https://modeling-how-to-learn.connpass.com/event/242944/ にてお話した際のプレゼン資料です。 入門者に向けて、テーブルを設計する上でモデリングすると良いよという話をしました。（熟練者は、そうだよねーっておさらいするか、そこは別の考え方があるんじゃないなどを呟いて貰えればといった内容です） モデリングして設計する際に、色々なモデルがあります。その中で、データモデルは静的な要素が強いモデルなので、モデリング全般を考えた際に、入門者にとって捉えやすいのではと考えています。 テーブルを設計する上で、データモデリングをしてデータモデルを作ることで、より良いテーブル構造を考えやすくなります。 #テーブル設計 #モデリング #データモデル #RDRA #概念モデ
DB設計の共有で疲弊してない？dbdocsのすゝめ
DB設計の管理や作成に疲弊してません？こんにちは。ukmshiです。今日はDB設計の共有と管理に便利なツール、dbdocsについてお話しします。dbdocsを使えば、設計の可視化や共有がめちゃくちゃ簡単になるんです。今回は、その魅力と利点、そして実際の使い方について詳しく説明します。 dbdocsとは？ dbdocsは、コードベース（DBML）でDB設計を管理し、URLで共有することが可能なツールです。データベースのテーブル構造や関係性を可視化し、それを他のチームメンバーやステークホルダーと手軽に共有することができます。 DBMLについてはこちらを参考に dbdocsの利点 dbdocsの利点について詳しく見ていきましょう。 無料 まず最初に、dbdocsは基本無料です。コストを気にせずに利用できるので、チームの誰もがアクセス可能です。 コードベースで管理 dbdocsはコードベースでDB
PHPerKaigi2024 の登壇資料です。 履歴データテーブルとの向き合い方 https://fortee.jp/phperkaigi-2024/proposal/47cf9f17-825a-4021-bf33-86e4a62bc222
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
詳細設計の書き方 - Qiita
はじめに システム開発において詳細設計という工程があります。 プログラマーはこの詳細設計を確認しながら開発を行うことになります。そのため詳細設計ではシステムの構造や仕様、動作などを細かく定義することが必要になります。 詳細設計を行うことでシステム開発の方向性が明確になり、コーディングやテストをスムーズに行うことができます。 詳細設計の成果物としてはクラス図やシーケンス図、画面設計書やデータベース設計書などがあり、システムの動きや機能を具体的に表現するものです。 今回は詳細設計を作成する機会があったので、詳細設計の書き方についてまとめたいと思います。 詳細設計の目的やメリット 詳細設計の目的は、システム開発の品質や効率を向上させることです。詳細設計では、システムの仕様や動作を細かく定義することで、以下のようなメリットがあります。 開発工程でのバグや遅延を減らすことができる テスト工程での不具
前提 前提ですが。 transaction=Consistency/Isolationを担保する仕組みの話とする。 一般にtransactionが持つべき属性はACIDと言われる。C/Iに比べて、A/Dが“わかりやすい”のでAtomic/Durableの属性の方が人口に膾炙しているが、現在のtransactionではA/Dネタはあまり話題にならない。A/Dネタはローカルだけで見るのであれば普通にfile system /storageの話になる。元来Atomic/Durableはtransactionのコンテクストでは専らlogging / recoveryの話だった。そして、これは非同期のepoch-basedになるとそれ自体の取り扱い優先度が下がる。現代的なtransactionでは、「現時点ではread committedが保証されているFS/storageでA/Dの問題は(ある程度
SQL Training 2021
Hands-on / Kaname Frusawa / Cloud Compare Users Meetup 2024 at University of Tokyo on April 17
3値論理
なぜ「= NULL」ではなく「IS NULL」と書かなくてはならないのか？ これは、気になっている人も多いはずです。まだ SQL に不慣れな頃、ある列が NULL である行を選択しようとして、 SELECT * FROM table_A WHERE col_1 = NULL; というクエリを書いてしまい、エラーになったり思い通りの結果が得られなかった、という経験は、ほぼ全ての人が持っているでしょう。ちょうど C言語や JAVA を習い始めのころに「if (a = 5)」と書いてしまう間違いとよく似ています。最初は、言語仕様の汚さにぶつぶつ文句をいいながらも、そのうち「IS NULL」という書き方に慣れてしまって、疑問を持たなくなります。 でもどう考えても奇妙な書き方ですよね。こんな素直でない書き方をしなくてはならないということには、やはりそれなりの理由があるのです。今からその理由を説明しま
【入門】データベース設計まとめ - Qiita
はじめに 今回はデータベース設計について学び直したので内容をまとめていきます。 自分は2021年に新卒でWeb系の開発会社にフロントエンジニアとして入社し2022年で2年目になります。 実務ではNext.js×TypeScriptを利用したフロントの開発をメインで行っています。 直近の開発案件でRailsを使ったサーバーサイドの開発を担当することになり、DB設計を触ったのですが体系的な理解をしていなかったので苦戦をしました。 実装はできたものの、データベース設計を「なんとなくの理解」で終わらせないように、体系的に学び直しました。 データベース設計の学習に関しては下記の書籍を参考に進めました。 スッキリわかるSQL入門 達人に学ぶDB設計 徹底指南書 対象者 データベース設計について基礎から学びたい人 何となくデータベースの設計をしている人 正規化について学びたい人 データベースとDBMS
最近、この説明を複数回したので記事にする。 要約 普段は 今北産業 派なのだが、3行考えるのが面倒なため、今後は大人の表現を使う。 「今北産業」をスタートアップ語にすると「マジ価値サマリー」になるらしい ちなみにここだけの話ですが、大人語にすると「要約」になります pic.twitter.com/Q8SflvBX7c— ところてん (@tokoroten) 2022年1月24日 画面に表示したい順(以下、表示順）は振る舞いの属性なので分ける 似たような振る舞いに関わる属性は別テーブルにわけると良い 普通に正規化しましょうって話。 表示順をカラムを追加して表現する よくあるテーブルは画面情報と合わせて表示順カラムがあるパターン。 こういうテーブルを作って SELECT * FROM items ORDER BY display_order_number; で表示順に取り出すパターン。 表示順
【イチから理解するサーバーレスアプリ開発】 サーバーレスアプリケーション向きの DB 設計ベストプラクティス 20190905版
2019/09/05 に開催された AWS のイベント、「イチから理解するサーバーレスアプリ開発」における講演資料の一つです。 ・サーバーレスアプリケーションにおいて Amazon DynamoDB が利用しやすい理由 ・RDB と DynamoDB の設計プロセス・考え方の対比・明文化 ・実例に沿った DynamoDB の設計プロセス解説とサンプル例題 などを含みます。Read less
並べ替えできるデータをデータベースに保存する方法
システム開発を行っているとよく、クライアントからデータを任意の順番に並び替えたいという要望があります。並び替えを実行するプログラムは、配列の順序を変えるだけなので簡単ですが、その順序をデータベースにどうやって保存するかという点についてはいつも迷ってしまいます。 これには色々なやり方がありますので、まとめてみました。 8つの方法 今回は8つの方法に分けてみましたが、いくつかの方法は組み合わせて使えると思いますし、さらに工夫した方法もあると思います。方法1～6は大きなくくりとしてよく見かけるものです。方法7方法8は私が考えたもので見たことがないし私自身も実装したことが無いのですが、飛躍したアイデアでもないので載せました。 対象のデータベースは主にRDBですが、KVSに向いているかどうかも（良い・普通・悪い）の3段階で書いています。 データ構造と使い方の説明は書いていますが、具体的な実装は書いて
赤いラクダは3倍早い！ピーク時毎分1400件を捌くための決済処理のチューニング紹介 - pixiv inside
こんにちは、4月からBOOTH部になったorekyuuです。 この記事では、転属後の一番大きな成果である、BOOTHで発生する大量の注文(ピーク毎分約1400件)を整合性を取りつつ高速にさばく改善について解説します。 BOOTHが抱えていた課題 まずはBOOTHが抱えていた課題について説明します。 BOOTHでは販売開始時刻が事前に予告されていた場合などの理由で瞬間的に決済が集中し、サーバーが大量の注文に耐えきれないケースが度々ありました。 その原因は在庫の処理にありました。擬似コードですが、注文の処理は以下のようになっていました。 def checkout! ActiveRecord::Base.transaction do 商品の悲観的ロック # 在庫数を同時に編集しないようにロックを取る 商品の在庫の減算処理 注文を確定済みにする 決済の請求APIを叩く end end 上記のコード
問題 多対多の関連を作るときの交差テーブル（中間テーブル、関連テーブルなどとも呼ばれる）にどのような名前をつけていますか？ 2つのテーブル名を単純につなげた users_magazines のような命名を見かけますが、これはあまり良い名前ではありません。 実体関連モデル - Wikipedia 実体 (entity) は名詞に対応すると考えることができる。例えば、コンピュータ、従業員、楽曲、数学的定理といった名詞である。 関連 (relationship) は2つの実体間の関係を捉えたものである。関連は2つ以上の名詞句を結び付ける動詞に対応すると考えることができる。例えば、企業とコンピュータの間の「所有する」(owns) という関連、従業員と部門の間の「監督する」(supervises) という関連、アーティストと楽曲の間の「演奏する」(performs) という関連、数学者と定理の間の「
RLSを用いたマルチテナント実装 for Django by Takayuki Shimizukawa 複数のテナント（チーム・組織）向けにサービスを提供するシステムで、テナント相互の情報を分離して扱う、複数のマルチテナントアーキテクチャが考案されています。「各プログラマが努力して実装する」戦略でも実現はできますが、プログラミングミスや設定間違いによるデータ混濁が高確率で発生します。このトークでは、マルチテナントアーキテクチャにおけるデータ分割アプローチのひとつ「共有アプローチ」をDjangoとPostgresのRow Level Security (RLS) の組合せで安全に実現する方法を紹介します。またこの方法のメリット、デメリットを紹介します。 https://djangocongress.jp/Read less
[RailsWorld 2023] Untangling cables & demystifying twisted transistors
データモデルKata - kawasima
社員は退職しても別のイベントデータと関連付けされているので、消せないことが多いでしょう。ただ氏名等個人情報に関わるものは持たないようにしなくてはならないので、サブタイプで区別します。
JavaScriptにおいて、ある配列をもとにして別のオブジェクトを作成する場合、Array#reduceを使用することが多い。 const input = ['foo', 'bar', 'baz']; const result = input.reduce((accumulator, currentValue) => { accumulator[currentValue] = capitalize(currentValue); return accumulator; }, {}); assert.deepStrictEqual(result, { foo: 'Foo', bar: 'Bar', baz: 'Baz' }); しかし例のように、単にキーと値の組み合わせにマッピングするだけなら、あえてArray#reduceを使うまでもない。代わりにObject.fromEntriesを使え
問題 最近、あるテーブルに started_at って名前のカラムをつけてしまったんだけど、あまりよくないっぽい。（あまり深く考えずに、created_at とか同様に過去分詞_atでいいだろと思って命名した。） 解説 start や end は自動詞にも他動詞にもなれるんだけども、例えば Campaigns というテーブルに対して、start した datetime を格納するためのカラムを追加するときは、Campaign が主語になり、「キャンペーンが始まる」という意味の自動詞にするのが自然とのこと。こうすると、自然言語では「The Campaign starts at 9 PM today.」とかなるので、starts_at と命名するのが自然っぽい。 現場 インターネット で検索してみたら、あるあるなのかなぁ 〜 日付のカラム名、started_at にするか start_at に
LaravelDB.com
Sponsor[Developer] キムラ ケイトさん（ウイッシュリスト）、 @pcb(ぱんかれ)（ウイッシュリスト）, スリヤツキ ビャチェスラフ（ウイッシュリスト）、イワサワさん（ウイッシュリスト）、ヤスノリさん×2、青木ヨウスケさん×3、健一さん、ヒトミさん、岩下ヒロシさん, 中村タイチさん, 川野ショウタロウさん, タツヤさん, ハルアキさん, **71さん, **08さん(8回),ツカサさん, **84さん, サトシさん, シホリさん, 駿平さん、トモノブさん、今林さん, ヨウスケさん ,KTPさん [01/07] Changes to the terms of use for "commercial use" [10/24] Please use "The Unarchiver" for ZIP file conversion on Mac [OS: Catalina] [0
— 脱RDB脳 — Cassandraのデータモデルについて考えてみる | フューチャー技術ブログ
はじめにこんにちは、Technology Innovation Group所属 DBチームの岩崎です。 私はDBチームとして様々なプロジェクトでOracleやPostgreSQLなどRDBの設計・構築に携わってきました。 現在は、Cassandraの導入とデータモデルを設計しています。 本稿ではDBネタとしてRDB脳から脱却して、KVSならではのテーブル設計の勘所をお伝えいたします。 CassandraはどのようなデータベースなのかCassandraはKVS(Key-ValueStore）と呼ばれ、KeyとValueを組み合わせる単純な構造からなるDBです。 データアクセスはkeyに対して行い、Keyに関連付けられたValueが呼び出されます。 KVSは一般的にスキーマレスを採用することが多いと思いますが、Cassandraではアプリケーションの観点から見て、データは構造的に扱える方が開発
ほんまに一対多でええんか？
こんにちは。株式会社プラハCEOの松原です。 今日は「ほんまに一対多でええんか？最初から多対多テーブルにしておいて備える方法もあるよ」というDB設計周りの話について書いてみます 一対多が多対多になる時に備える こういうユースケースに直面した時・・・ ユーザーは記事を複数作成できる 脊髄反射的にこういうテーブル構成が採用されるのを見かけます 「記事を作成するユーザーは一人なんだからこれで問題ないのでは？何が言いたいの？言いがかり？そういうの人として恥ずかしくない？」と思われるかもしれませんが、後々サービスの性質が変わって 複数ユーザーで記事を共同作成できる というユースケースが加わった時には中間テーブルを新規作成して既存データを移し替えるような本番DBのマイグレーション作業が必要になります 最初から中間テーブルにしておくパターン もしauthorという中間テーブルを作ってarticle_id
drawSQL https://drawsql.app/ drawSQLの特徴 「drawSQL」は、実際にありそうなER図をフォークしてRDBのエンティティ設計ができるデザインツールです。 アプリケーションのテーマやプログラミング言語ごとに約200以上の種類が用意されています。 ベースにしたいER図を見つけたら「Clone」で作成を開始。 新規につくるほか、既存のER図に差し込むこともできます。 キャンバスにクローンされたER図が表示されたら準備完了。 既存のテーブルにカラムを追加したり 新しいテーブルをつくって、リレーションを張ったりすることもできます。 もちろん、テンプレートを利用せずにスクラッチでER図を作成することも可能。現在は、MySQL・PostgresSQL・SQL Serverの3つに対応しています。 個人開発や初期のプロダクトづくりに、重宝するツールではないでしょうか。
The other day, while in a planning poker session, the question of the naming of a particular table arose. During that conversation, one of our developers suggested that the table shall have a singular name, while others questioned that idea and thought that every table names should be plural. This led me to ask this question: is there a better choice? Should table names be singular or plural? It’s
▼ 高画質版はこちらから（内容は同じものとなります） https://youtu.be/hothDfIeEOU ▼ ハッシュタグ #LAPRAS公開設計レビュー LAPRASでは、新規機能開発の際、そーだいさんのブログ等を参考にさせていただくことが多くあります。 我々が作った設計について、よりよいものとするために、DB設計の雄であるそーだいさんに相談する場を頂戴しました。 実際のLAPRASの求人機能のDB設計を元にそーだいさんに質問を投げかける形式で実施する勉強会をせっかくなので収録し、公開しようと思います。 ▼ イベントページ 公開設計レビュー「LAPRASのDB設計についてそーだいさんに相談してみた」 https://lapras.connpass.com/event/214564/ ■ 動画内で言及されている説明資料(PDF) https://drive.google.c
マスター系テーブルの主キーにいちいち「適用開始日」や「履歴番号」が含まれているDB設計を見たことはないだろうか。品目マスターを例にすると主キーが｛品目№｝ではなく、｛品目№＋適用開始日｝とか｛品目№＋履歴番号｝のようになっていたりする。このように設計した場合、他テーブルとの間に成立しているはずの豊かな関係が見えなくなる（図１）。結果的に、システム仕様の可読性や保守性が著しく低下する。 図１．適用開始日を主キーに含むとテーブル関連が見えない ここでは「適用開始日」が主キーに含まれるケースを前提にして話を進めよう。この奇妙な設計方針を採用しているユーザ企業に話を聞く機会があったのだが、それなりの理由が２つあることがわかった。そのシステムがマルチテナント方式で顧客に提供しているサービスにおいて、各顧客が定義したマスターの更新履歴を保持することが求められているため。もうひとつは、それらのマスター値
イミュータブルデータモデリング Q. イミュータブルデータモデリングについて教えてください。 A. 以下、ChatGPT の回答です。 イミュータブルデータモデリング（Immutable Data Modeling）は、データモデリングのアプローチの一つで、データを不変（変更不可）な形式で扱う方法です。このアプローチでは、データが一度生成されたら、その値を変更せず、新しいバージョンを作成することが一般的です。イミュータブルデータモデリングは、分散システム、バージョン管理、データの整合性、履歴のトラッキングなどのさまざまな領域で有用です。 以下は、イミュータブルデータモデリングの主要な特徴と利点です。 データの安定性と信頼性: データが不変であるため、一度データが記録されたら、それを変更することができないため、データの信頼性と安定性が向上します。これは、エラーやバグがデータを破損させる可能性
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
社内SQL研修のために作った資料を公開します | 株式会社AI Shift
データベース設計の際に気をつけていること - 食べチョク開発者ブログ
決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料
データベース設計におけるNULL - kawasima
イミュータブルデータモデル - kawasima
本当にあったやらかしDB設計シリーズ一覧 - Qiita
SQLアンチパターンもりもりDBを設計しよう！ - Qiita
最強データベース（RDB）設計とは？アンチパターンの見極め方法も - FLEXY（フレキシー）
Database schema templates by DrawSQL
超入門！テーブル設計をデータモデリングから考えよう
履歴データテーブルとの向き合い方_PHPerKaigi2024
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
本当にtransactionは必要なのか？ - 急がば回れ、選ぶなら近道
表示順という属性を別テーブルに分ける - そーだいなるらくがき帳
交差テーブルには関連の意味を表す名前をつけよう - Qiita
RLSを用いたマルチテナント実装 for Django
はじめてのB2B SaaSデータモデリング in Builderscon 2019
Object.fromEntriesを活用してArray#reduceを代替する
started_at ってカラム - 線路は続くよどこまでも。
実際にありそうなER図をフォークしてRDBのエンティティ設計ができる「drawSQL」
The table naming dilemma: singular vs. plural
公開設計レビュー「LAPRASのDB設計についてそーだいさんに相談してみた」
更新履歴と更新予約を「時限属性」で合理化する - 設計者の発言
イミュータブルデータモデルにおける "削除フラグ" の表現
kyounotenshi.hatenablog.com
apps.apple.com
www.smt-cinema.com
aizine.ai
848unagi.wixsite.com
aoringo723.hatenablog.com