https://novice.blog.shinobi.jp/ Sun, 01 Feb 2026 02:53:59 GMT ja © Ninja Tools Inc.
RDSについて整理する。

第一章　DBを制する者はシステムを制す
第二章　論理設計と物理設計
第三章　論理設計と正規化
第四章　ER図
第五章　論理設計とパフォーマンス
第六章　データベースとパフォーマンス
第七章　論理設計のバッドノウハウ
第八章　論理設計のグレーノウハウ
第九章　一歩進んだ論理設計　SQLで木構造を扱う

第一章　DBを制する者はシステムを制す
　　ソフトウェア開発の歴史
　　　　プロセス中心→データ中心
　　　　　　データより、業務処理はよく変わるため
　　　　要件定義→設計→開発→テスト→運用
　　　　　　プロセス中心（要件定義～テスト）
　　　　　　データ中心（要件定義～運用）
　　　　　　DDD（要件定義～運用）
　　　　　　データドリブン（運用）
　　　　　　　　　実運用データを収集し、システムの改善や機能追加をデータに基づいて行う。
　　　　各工程で共存できるできないの相性はある
　　外部スキーマ→概念スキーマ→内部スキーマ
　　　外部スキーマ：ユーザーインターフェースや入力データ（ユーザーから見えるもの）
　　　概念スキーマ：データ同士の関係（設計書レベル）
　　　内部スキーマ：DBのメタデータ（インデックスのデータ構造など、通常見えない情報）
第二章　論理設計と物理設計
　　テーブル定義→インデックス定義→ハードウェアサイジング→ストレージ冗長構成→ファイルの物理配置
　　　　サービス終了時のデータ量を見積、それに耐えうるようにする。（または計画があれば可）
　　　　ストレージ冗長構成：少なくともRAID５　余裕があれば10 ０は絶対ダメ
　　バックアップ方式：フルバックアップ＋差分or 増分バックアップ　が一般的
第三章　論理設計と正規化
　　正規化
　　１：１つのセルに１つの値
　　２・３：(部分関数or推移的関数)従属の解消（特定のカラムの値が決まれば、一意に決まるカラムが存在しない　テーブル分割を行う）
　　第３正規化まで実施する。
　　　　メリット：更新時の不整合の防止、データの持つ意味が明確になり理解しやすい。
　　　　デメリット：結合時性能悪化する。
第四章　ER図
第五章　論理設計とパフォーマンス
　　例　注文の商品数のサマリカラムの追加のケース（非正規化）
　　検索パフォーマンスを向上させるに非正規化は有効だがリスクが大きい
　　　　更新パフォーマンスの低下
　　　　データのリアルタイム性の低下
　　　　後続の工程で設計変更すると手戻りが大きい
第六章　データベースとパフォーマンス
　　インデックスと統計情報
　　インデックスの内部構造
　　　　データ構造（キー値・ポインタをBツリー構造で持つ）
　　　　　　上記が整理された状態で保持（データ更新のたびにここも更新される。）
　　　　データの検索速度が上がる。
　　　　B-tree：平衡木で探索距離が均一　フルスキャンO(n),BtreeO(log n )
                             CRUDすべてについて性能が向上
　　インデックス作成場所
　　　　・データ1万以上のテーブル
　　　　・カーディナルが高い列
　　　　・SQLのWHERE・結合条件で利用される
　　　　※主キーや一意制約のカラムには不要（内部で自動で作成されている）
　　インデックスが効果ないもの
　　　　・インデックス列に演算したとき　col_a * 1.1 > 100（col_a  > 100/1.1 はOK）
　　　　・SQL関数を使用したとき　SUBSTRなど
　　　　・IS　NULLを利用したとき
　　　　・否定を利用したとき　＜＞
　　　　・ORを利用したとき　（INはOK）
　　　　・後方一致、中間一致のLIKEを利用したとき
　　　　・暗黙の型変換を利用したとき col_a(文字列の時） = 1 (　col_a = '1'はOK)
　　　統計情報
　　　　　SQL実行時この統計情報は計算され更新される。
　　　　　必ずしも良い計算結果にならないので更新を止めることも可能。
第七章　論理設計のバッドノウハウ
　　　キーには固定長文字列のコードが望ましい
第八章　論理設計のグレーノウハウ
　　　代理キーを利用せず、自然キーを主キーに利用するのが望ましい
第九章　一歩進んだ論理設計　SQLで木構造を扱う
　　　SQLで木構造のデータを保存するのは難しい
　　　　　例　部署情報など
　　　解決法として隣接リストモデルなどある]]> 未選択 https://novice.blog.shinobi.jp/%E6%9C%AA%E9%81%B8%E6%8A%9E/db%E8%A8%AD%E8%A8%88 Sun, 20 Apr 2025 08:10:21 GMT novice.blog.shinobi.jp://entry/3
状態管理機能
インターフェイス使う理由
B票の分析


設計歴史

プロセス中心
データ中心
オブジェクト中心
　DDD　業務要件の理解
データセット　データ整理、エンティティ、リレーション


4月
デザイン
DB設計
Spring(@Bean @Component @bport)
DDD
React


DBの管理
　DBのチューニング
　　パフォーマンス管理
　　　ヒント句
　　　クラウド
　　　ネットワーク
　　　未来



個人によってフォーカスしたい問題が変わる

ドメイン駆動設計で保守性をあげたリニューアル事例 〜 ショッピングクーポンの設計紹介 - Yahoo! JAPAN Tech Blog

なぜDDD初心者はググり出してすぐに心がくじけてしまうのか - Qiita


JAVA
　　JJUG

Quita
Zenn
note
WebDesginTrend
Developers.IO
　  キーワードを見つけるため
stackover flow
 　how to resolve
 　errorの内容で検索

]]> 未選択 https://novice.blog.shinobi.jp/%E6%9C%AA%E9%81%B8%E6%8A%9E/%E8%A8%AD%E8%A8%88%E5%8B%89%E5%BC%B7%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%83%A1%E3%83%A2 Wed, 06 Apr 2022 00:40:11 GMT novice.blog.shinobi.jp://entry/1