データベース設計

→データベース関連

一般†

• 超入門！テーブル設計をデータモデリングから考えよう - Speaker Deck 2024.1

• 【入門】データベース設計まとめ #Rails - Qiita 2023.11

• 【随時更新】テーブル設計でミスらないために確認したいアンチパターン - Qiita 2023.9

• DB設計の共有で疲弊してない？dbdocsのすゝめ 2023.5

• 論理削除が云々について - mike-neckのブログ 2015
  • テーブルに状態を持たせない
  • 究極には機械が認識するキーと、人間にとって意味のあるデータだけのエンティティだけですべての業務のデータを構成できる
  • 日付を持つデータはイベント(これもひとつのエンティティ)
  • NULLのデータは絶対に持ってはならない
  • テーブルはでかく作るな、小さく作れ
  • テーブル同士の関連は直接持つな、関連を表すテーブルを作れ
  • 1:1の関連になったとしても、イベントとそれに付随するデータは分離しろ
  • データが増える？金と物理で殴れ(ディスク増強しろ)

• データベースの概念スキーマ、外部スキーマ、内部スキーマ - Qiita 2020
  • 外部スキーマ…ユーザから見たときの見た目。ビューに相当
  • 概念スキーマ…CRETE TABLEなどのDDLに該当。データモデル
  • 内部スキーマ…DBの実装。ファイルやインデックスなど

• M1Mac × Docker × SchemaSpy × MySQL8.0でテーブル定義書とER図を自動生成してみる 2022.10

• 【入門】データベース設計まとめ - Qiita 2022.8

• シャーディングは、特定のタイプのパーティション分割であり、いわゆる水平パーティション分割の一部です。
• シャーディング - Qiita 2019
• シャーディングとは、テーブルシャーディングという可能性【水平分割】 | SEO対策なら株式会社ペコプラ 2020

• DB設計について考えてみた。ナチュラルキーとサロゲートキーはどちらが良いのか？ | 株式会社AMG Solution 2022.4

• 交差テーブルには関連の意味を表す名前をつけよう 2019.6

• DB設計時のサイズ見積もり

• リレーションの正規化
  • 第１〜第５正規形の説明、ボイス・コッド正規形の説明など

• フリーで使えるDBモデリングツールまとめ
  • Clay,DBDesigner4, MySQL Workbench,WWW SQL Designer,A5:SQL Mk-2, Execute Query
• DBDesigner4 MySQL用のDB設計ツール

ER図†

→ドキュメント作成

• SchemaSpyを使用してRDBからER図を自動生成する 2024.4

• 【DB設計】テーブル定義（クエリ）からER図の自動生成 | ジコログ 2024.3

• MermaidでER図を書く - エキサイト TechBlog. 2023.11

• ChatGPTを使ってDDLからER図をすばやく作成する - Taste of Tech Topics 2023.8

• 【DB設計】既存データベースからER図のリバース生成（自動生成） | ジコログ 2023.8
  • A5M2で生成

• ChatGPTにER図を作成してもらってみた | DevelopersIO 2023.3

• tblsでデータベースドキュメントを生成する（1.ドキュメント生成編） - Qiita 2018

• PlantUMLでER図を書く - Qiita 2022.10

• ER図をマウスを使わないで書きたいし、その内容をGitLabで管理もしたい - Qiita 2022.9

• ER図の自動生成について、dbdiagram.io, DBeaver, A5M2 を比較してみる。 - Qiita 2022.8

• ER図の作図について、 Draw.io, PlantUML, Mermaid を比較してみる。（VSCode拡張機能など） - Qiita 2022.7

• ブラウザでER図が描けるWWW SQL Designer紹介
  • http://ondras.zarovi.cz/sql/
• ER図
• 誰でもかけるER図

インデックス†

• インデックスを理解したい #SQL - Qiita 2024.3
• RDBMSのインデックスの概略的なまとめ – サイゼントの技術ブログ 2024.3
• 図解 DB インデックス 2023.5

mixiはいかにして増え続けるトラフィックに対処してきたか†

• http://itpro.nikkeibp.co.jp/article/NEWS/20060330/233820/
• Webサーバーは単純に増やせばいいのであまり問題にならない。
• MySQLのスケーラビリティをどう確保するか
  • mixiは更新処理が多いためレプリケーションはあまり有効ではない
  • そこでまずデータベースの分割で対応
    • テーブルの種類によるＤＢの分割

      ・テーブル位置の管理情報をもつパーティションマップを作成
         ・利点：DB移行が楽（管理情報を書き換えるだけで良い）
         ・欠点：テーブルの結合ができなくなる(開発当時は）

  • この対応でもおっつかなくなった
  • 次にユーザ単位でのDB分割
    • パーティション・マップ用DBの追加
    • アプリケーションの中だけでパーティション・マップを処理
  • (これらはパーティション・マップが増えることへの対応か？）
  • DB分割によるコネクションの増加→メモリ・キャッシュで対応
  • 将来は更新日時によるデータ分割も検討する

最新の50件