RDB THE Right Way - builderscon 2018/ RDB_THE_Right_Way

buildersconでの登壇資料です。

https://builderscon.io/tokyo/2018/session/ddba9bd5-819e-489e-9123-04d2291d506e

当日の動画は後ほど上記のリンク先で公開されます。

Transcript

1. RDB THE Right Way ~壮大なるRDBリファクタリング物語~ builderscon tokyo 2018
3. What is it? 待望の続編
4. What is it? RDB THE Right Way?
5. What is it? RDBの正しい道
6. What is it? RDBの正しい設計
7. What is it? RDBの歩き方
8. What is it? データベースの寿命は アプリケーションより長い
9. What is it? 特定のRDBMSに依存した話 では無く、RDB一般的な話
10. What is it? RDBの正しい設計と それを目指す歩き方をご紹介します
11. あじぇんだ 1 自己紹介 2 THE Right Way 3 正しい道の歩き方 4 壮大なるリファクタリング 5 まとめ
12. あじぇんだ 1 自己紹介 2 THE Right Way 3 正しい道の歩き方 4 壮大なるリファクタリング 5 まとめ
13. 自己紹介 名前 : 曽根 壮大(そね たけとも) 年齢 : 33歳(3人の子供がいます) 職業 : 副社長/CTO 所属 : 株式会社 オミカレ 日本PostgreSQLユーザ会(JPUG) 勉強会担当 技術的にはLL系言語やRDBが好きです
14. 自己紹介 名前 : 曽根 壮大(そね たけとも) 年齢 : 33歳(3人の子供がいます) 職業 : 副社長/CTO 所属 : 株式会社 オミカレ 日本PostgreSQLユーザ会(JPUG) 勉強会担当 技術的にはLL系言語やRDBが好きです
15. 婚活といえばオミカレ https://party-calendar.net/
16. あじぇんだ 1 自己紹介 2 THE Right Way 3 正しい道の歩き方 4 壮大なるリファクタリング 5 まとめ
17. THE Right Way 正しい設計とは？
18. THE Right Way 論理設計と物理設計
19. THE Right Way 論理設計と物理設計
20. THE Right Way
21. THE Right Way Entity Relationship Diagram (実体関連図)
22. THE Right Way ERDを考える
23. THE Right Way ERDを考える ↓ モデリングする
24. THE Right Way ERDを作る || 論理設計
25. THE Right Way モデリングするために 必ず知るべきこと
26. THE Right Way データと情報は違う
27. SQLアンチパターン “さて、皆さんは「情報」と「データ」の違いをご存知でしょ うか。この二者の関係は「多くの情報を秘めた貴重なデー タ」という表現で言い尽くせます。いつでも我々が欲しいの は、意味のある(目的を持った)正しい情報なのです。一方、 データは単なる各種の事実の値(何らかの、名称とか日付とか 金額とか)であってそれ自体に目的はありません。” SQLアンチパターンのまえがき 和田 省二
28. SQLアンチパターン “「データ」を永続化して蓄えるのに適している のがRDBであり、それから「情報」を生成する のに適しているのがSQLなのです。” SQLアンチパターンのまえがき 和田 省二
29. THE Right Way データ（事実） と 情報（見たい内容）
30. THE Right Way データベースで扱うのがデータ アプリケーションで扱うのが情報
31. THE Right Way データ設計と情報設計は 分けることが大事
32. THE Right Way データ設計
33. THE Right Way データ設計 ↓ どのように事実を保存するか
34. THE Right Way 情報設計
35. THE Right Way 情報設計 ↓ 事実を如何に加工・利用するか
36. THE Right Way アンケートフォーム
37. • 全て必須とします • 名前は一意とします
38. THE Right Way どんなデータ設計をしますか？
39. THE Right Way 名前 トーク評価 理由 好きなDB その他 曽根 壮大 最高 ベストスピーカー PostgreSQL soudai1025 最高 なんとなく MySQL Soudai 最高 SQL Server hoge 普通 普通だった Oracle Fuga 悪い その他 Firebird
40. THE Right Way ほんとに？
41. THE Right Way 名前 トーク評価 理由 好きなDB その他 曽根 壮大 最高 ベストスピーカー PostgreSQL soudai1025 最高 なんとなく MySQL Soudai 最高 SQL Server foo hoge 普通 普通だった Oracle Fuga 悪い その他 Firebird アプリケーションのバグで入る
42. THE Right Way 名前 トーク評価 理由 好きなDB 曽根 壮大 最高 ベストスピーカー PostgreSQL soudai1025 最高 なんとなく MySQL Soudai 最高 SQL Server hoge 普通 普通だった Oracle Fuga 悪い その他 名前 その他 Fuga Firebird 「その他」のときだけ 別テーブルに切り出す
43. THE Right Way ほんとに？
44. THE Right Way 名前 トーク評価 理由 好きなDB 曽根 壮大 最高 ベストスピーカー PostgreSQL soudai1025 最高 なんとなく MySQL Soudai 最高 SQL Server hoge 普通 普通だった Oracle Fuga 悪い その他 名前 その他 Fuga Firebird Soudai foo アプリケーションのバグで入る
45. THE Right Way 情報優先でデータ設計をすると データに矛盾が生まれる
46. THE Right Way どうやって設計していくか？
47. THE Right Way どうやって設計していくか？ ↓ まずモデリングをする
48. THE Right Way どうやって設計していくか？ ↓ まずモデリングをする いきなりデータ設計しない！
49. THE Right Way Entity Relationship Diagram (実体関連図)
50. THE Right Way Entityを定義する
51. THE Right Way Entity ↓ イベント(コト)とリソース(モノ)
52. THE Right Way イベント
53. THE Right Way イベント ↓ 実際に発生したコト
54. イベントとは？ • 事実、つまり過去しかない • 定期的に繰り返される • Entityをとらえるには、5W2H
55. 5W2H • When（いつ） • Where（どこで） • Who（誰が） • What（何を） • Why（なぜ） • How（どうする） • How Much、How Many （いくら、いくつ）
56. THE Right Way イベントは WhenとHow to
57. 5W2H • When（いつ） • Where（どこで） • Who（誰が） • What（何を） • Why（なぜ） • How（どうする） • How Much、How Many （いくら、いくつ） 過去であるかどうか
58. 5W2H • When（いつ） • Where（どこで） • Who（誰が） • What（何を） • Why（なぜ） • How（どうする） • How Much、How Many （いくら、いくつ） 何が行われるか 繰り返されるか
59. THE Right Way リソース
60. THE Right Way リソース ↓ 登録するモノ
61. リソースとは？ • 事実を生み出す元 • 未来も定義できる • 概念も定義出来る
62. 5W2H • When（いつ） • Where（どこで） • Who（誰が） • What（何を） • Why（なぜ） • How（どうする） • How Much、How Many （いくら、いくつ）
63. THE Right Way リソースは WhenとHow to 以外
64. THE Right Way Entityを定義する
65. • 全て必須とします • 名前は一意とします • When（いつ） • Where（どこで） • Who（誰が） • What（何を） • Why（なぜ） • How（どうする） • How Much、How Many （いくら、いくつ）
66. • 全て必須とします • 名前は一意とします • When（いつ） • Where（どこで） • Who（誰が） • What（何を） • Why（なぜ） • How（どうする） • How Much、How Many （いくら、いくつ） アンケート結果は事実 ↓ イベント
67. • 全て必須とします • 名前は一意とします • When（いつ） • Where（どこで） • Who（誰が） • What（何を） • Why（なぜ） • How（どうする） • How Much、How Many （いくら、いくつ） アンケートの項目自体は？
68. • 全て必須とします • 名前は一意とします Whoだからリソース
69. THE Right Way 回答 回答者 好きなデータベース トーク評価 評価理由 データベースの種類
70. THE Right Way Entityを関連付ける ↓ Relationship ↓ 正規化
71. THE Right Way Entityを関連付ける ↓ Relationship ↓ 正規化
72. THE Right Way 回答 回答者 好きなデータベース トーク評価 評価理由 データベースの種類
73. THE Right Way 回答 回答者 好きなデータベース トーク評価 評価理由 データベースの種類 評価の理由だから 親子関係がある
74. THE Right Way 回答 回答者 好きなデータベース トーク評価 評価理由 データベースの種類 データベースの種類がない時、 その他ってリソースが必要では？
75. THE Right Way まず現実をモデリングする
76. THE Right Way まず現実をモデリングする ↓ Entity Relationshipすることで 必要なデータが見えてくる
77. THE Right Way まず現実をモデリングする ↓ Entity Relationshipすることで 必要なデータが見えてくる
78. THE Right Way リレーショナルモデルで定義する
79. THE Right Way リレーショナルモデルで定義する ↓ 正規化
80. THE Right Way データに矛盾がある
81. THE Right Way データに矛盾がある ↓ 関係従属は自明ではない
82. THE Right Way 正規化出来ていない
83. THE Right Way 名前 好きなDB 曽根 壮大 PostgreSQL soudai1025 MySQL Soudai SQL Server hoge Oracle Fuga Firebird 名前 選択肢 Firebird その他 PostgreSQL PostgreSQL MySQL MySQL Oracle Oracle SQL Server SQL Server SQLite その他 Db2 その他 ※DBのところだけ注目して正規化をした場合 データベースの種類 アンケート
84. THE Right Way 名前 好きなDB 曽根 壮大 PostgreSQL soudai1025 MySQL Soudai SQL Server hoge Oracle Fuga Firebird 名前 選択肢 Firebird その他 PostgreSQL PostgreSQL MySQL MySQL Oracle Oracle SQL Server SQL Server SQLite その他 DB2 その他 回答の事実はその他ではなく、DB名 データベースの種類 アンケート ※DBのところだけ注目して正規化をした場合
85. THE Right Way 名前 好きなDB 曽根 壮大 PostgreSQL soudai1025 MySQL Soudai SQL Server hoge Oracle Fuga Firebird 名前 選択肢 Firebird その他 PostgreSQL PostgreSQL MySQL MySQL Oracle Oracle SQL Server SQL Server SQLite その他 DB2 その他 ※DBのところだけ注目して正規化をした場合 主キーなので一意 データベースの種類 アンケート
86. THE Right Way 事実を正しく保存して 正しいデータを作る
87. THE Right Way
88. THE Right Way 理論を正しく理解して RDBを使いこなす
89. あじぇんだ 1 自己紹介 2 THE Right Way 3 正しい道の歩き方 4 壮大なるリファクタリング 5 まとめ
90. 正しい道の歩き方 考えたモデルから 正しいデータ設計を考える
91. 正しい道の歩き方 論理設計と物理設計
92. 正しい道の歩き方 物理設計
93. 正しい道の歩き方 物理設計 ↓ データをシステムとして どのように保存するか
94. 正しい道の歩き方 正規化した結果で 問題がない場合
95. 正しい道の歩き方 正規化した結果で 問題がない場合 データ設計もほぼ完成
96. 正しい道の歩き方 正規化した結果で 問題がない場合 データ設計もほぼ完成 参照したい情報とINDEXの相談
97. 正しい道の歩き方 正規化した結果で 問題がない場合 データ設計もほぼ完成 参照したい情報とINDEXの相談 多くのケースはここ
98. 正しい道の歩き方 正規化した結果だけでは 問題がある場合
99. 正規化だけで解決しない例 • パフォーマンス問題 • アプリケーションの制約 • システムアーキテクチャの制約
100. 正規化だけで解決しない例 • パフォーマンス問題 • アプリケーションの制約 • システムアーキテクチャの制約 • 正規化が細かく、JOINが多段 • テーブルサイズが大きい • 参照の条件が多い • 書き込み・更新がとても多い • INDEXが効かない …etc
101. 正規化だけで解決しない例 • パフォーマンス問題 • アプリケーションの制約 • システムアーキテクチャの制約 • ID必須 • DBマイグレーションが外部キー制約に 対応していない • JSONとか使いたい …etc
102. 正規化だけで解決しない例 • パフォーマンス問題 • アプリケーションの制約 • システムアーキテクチャの制約 • データストアが複数ある • セキュリティの制約がある • マイクロサービス化
103. 正規化だけで解決しない例 • パフォーマンス問題 • アプリケーションの制約 • システムアーキテクチャの制約 困る時の多くのケースはここ
104. 正しい道の歩き方 RDBMSの機能を使う
105. RDBMSの機能の利用例 • 制約を使ってデータを担保する • 特殊なINDEXを使って複雑なクエリを対処する • 拡張機能を利用して特別なケースに対応する
106. RDBMSの機能の利用例 • 制約を使ってデータを担保する • 特殊なINDEXを使って複雑なクエリを対処する • 拡張機能を利用して特別なケースに対応する
107. THE Right Way 名前 トーク評価 理由 好きなDB その他 曽根 壮大 最高 ベストスピーカー PostgreSQL soudai1025 最高 なんとなく MySQL Soudai 最高 SQL Server hoge 普通 普通だった Oracle Fuga 悪い その他 Firebird 「その他」の時だけ許可する CREATE TABLE enquete (“その他” text CHECK(“好きなDB” = ‘その他’), …);
109. RDBMSの機能の利用例 • 制約を使ってデータを担保する • 特殊なINDEXを使って複雑なクエリを対処する • 拡張機能を利用して特別なケースに対応する • 式INDEX • 列指向INDEX • フルテキスト INDEX • GIN INDEX …etc
110. RDBMSの機能の利用例 • 制約を使ってデータを担保する • 特殊なINDEXを使って複雑なクエリを対処する • 拡張機能を利用して特別なケースに対応する • DBlinkやFDWで外のDB(NoSQLを含む)を参照する • パーテーションでテーブルを分割する • マテリアライズド・ビューで集計結果をキャシュする
111. 正しい道の歩き方 データは常に成長する
112. 正しい道の歩き方 データは常に成長する ↓ 量は増え、質は変化する
113. 正しい道の歩き方 今日が正しかったことが 来年は正しいとは限らない
114. 正しい道の歩き方 だからこそ常に正しさを問う
115. 正しい道の歩き方 だからこそ常に正しさを問う ↓ 正しい設計は常に変化する
116. 正しい道の歩き方
117. 正しい道の歩き方 データベースの問題は 忘れた頃にやってくる
119. https://speakerdeck.com/soudai/rdb-antipattern-refactoring?slide=94
120. あじぇんだ 1 自己紹介 2 THE Right Way 3 正しい道の歩き方 4 壮大なるリファクタリング 5 まとめ
121. 壮大なるリファクタリング 変化するデータベースに 対応していく
122. 壮大なるリファクタリング データベースの不吉な匂い
123. 壮大なるリファクタリング データベースの不吉な匂い ↓ 技術的負債
124. 壮大なるリファクタリング DBリファクタリングの勘所
126. 壮大なるリファクタリング 動画も資料もあるので 去年の資料を見てくれ！
127. 壮大なるリファクタリング スーパーテーブル 作ってませんか？
128. 壮大なるリファクタリング テーブルの責務
129. 壮大なるリファクタリング テーブルの責務 ↓ クラスの責務に似てる
130. 壮大なるリファクタリング • 行毎に複数の状態を持っている • 値によって意味が変わる • 特定の列の値で、他の列の値の意味が変わる • 一つのテーブルが色んな用途で使われる …etc
131. 壮大なるリファクタリング • 行毎に複数の状態を持っている • 値によって意味が変わる • 特定の列の値で、他の列の値の意味が変わる • 一つのテーブルが色んな用途で使われる …etc delete_flagとか
132. 壮大なるリファクタリング • 行毎に複数の状態を持っている • 値によって意味が変わる • 特定の列の値で、他の列の値の意味が変わる • 一つのテーブルが色んな用途で使われる …etc スマートIDとか (先頭の数値が9だと管理者とか)
133. 壮大なるリファクタリング • 行毎に複数の状態を持っている • 値によって意味が変わる • 特定の列の値で、他の列の値の意味が変わる • 一つのテーブルが色んな用途で使われる …etc EAV (Entity Attribute Value)
134. 壮大なるリファクタリング • 行毎に複数の状態を持っている • 値によって意味が変わる • 特定の列の値で、他の列の値の意味が変わる • 一つのテーブルが色んな用途で使われる …etc B to CのサービスでUserテーブルに 会員と管理者が混在するなど
135. 壮大なるリファクタリング
136. 壮大なるリファクタリング とにかく読んで欲しい
137. 壮大なるリファクタリング テーブルの責務を分ける
138. https://soudai.hatenablog.com/entry/2018/05/01/204442
139. 壮大なるリファクタリング テーブルのスコープを小さくする
140. 壮大なるリファクタリング 名前 トーク評価 理由 好きなDB その他 曽根 壮大 最高 ベストスピーカー PostgreSQL soudai1025 最高 なんとなく MySQL Soudai 最高 SQL Server hoge 普通 普通だった Oracle Fuga 悪い その他 Firebird
141. 壮大なるリファクタリング 名前 トーク 評価 理由 好きなDB 曽根 壮大 最高 ベストスピーカー PostgreSQL soudai1025 最高 なんとなく MySQL Soudai 最高 SQL Server hoge 普通 普通だった Oracle Fuga 悪い その他 名前 選択肢 Firebird その他 PostgreSQL PostgreSQL MySQL MySQL Oracle Oracle SQL Server SQL Server SQLite その他 DB2 その他 DBの種類 アンケート
142. 壮大なるリファクタリング トリガーで分ける
143. 壮大なるリファクタリング アンケート アンケート トリガー アプリ DBの種類
144. 壮大なるリファクタリング
145. 壮大なるリファクタリング 担当のデータベース テーブルを全て把握してますか？
146. 壮大なるリファクタリング データベース考古学
147. 壮大なるリファクタリング TABLE一覧を眺める会
148. 壮大なるリファクタリング Batchから紐解く
149. 壮大なるリファクタリング 現状をまず把握する
150. 壮大なるリファクタリング 現状をまず把握する ↓ 正しい姿の設計をする
151. 壮大なるリファクタリング 現在地とゴールまでの距離を測る
152. 壮大なるリファクタリング 現在地とゴールまでの距離を測る ↓ あとは少しづつ改善していく
153. 壮大なるリファクタリング 問題は先送りすると より大きな問題を連れてくる
154. あじぇんだ 1 自己紹介 2 THE Right Way 3 正しい道の歩き方 4 壮大なるリファクタリング 5 まとめ
155. まとめ データベースの寿命は アプリケーションよりも長い
156. まとめ データは失うと取り戻せないし、 情報はデータが無いと作れない
157. まとめ だからこそ正しい事実を保存する
158. まとめ 解決した問題の大きさが エンジニアの価値
159. https://speakerdeck.com/soudai/rdb-antipattern-refactoring?slide=94
160. まとめ 覚悟を決めるには根拠が必要
161. まとめ 覚悟を決めるには根拠が必要 ↓ 根拠は技術で解決できる
162. まとめ 数冊の本を読むだけで 充分な知識がつくのがRDB
163. まとめ 技術で問題を解決していく
164. まとめ 技術で問題を解決する ↓ 解決までの歩んだ轍が道になる
165. まとめ RDB THE Right Way
166. まとめ RDB THE Right Way ↓ あなたの道を歩くのはあなた自身
167. まとめ 技術で問題を解決していく
168. ご清聴ありがとうございました