Slide 1
Slide 1 text
失敗から学ぶRDBの正しい歩き方
オープンセミナー2018@香川
Slide 2
Slide 2 text
What is it?
みなさん失敗したことありますか？
Slide 3
Slide 3 text
What is it?
みなさん失敗したことありますか？
↓
私は沢山あります
Slide 4
Slide 4 text
What is it?
あの時、どうすればよかったか…
Slide 5
Slide 5 text
What is it?
“愚者は経験に学び、賢者は歴史に学ぶ。”
--オットー・ビスマルク
Slide 6
Slide 6 text
What is it?
他人の失敗を知ることで
自分の失敗を未然に防ぐことが出来る
Slide 7
Slide 7 text
本を書きました
https://www.amazon.co.jp/exec/obidos/ASIN/4297104083/maple036-22/
Slide 8
Slide 8 text
What is it?
RDBMSの失敗例集
Slide 9
Slide 9 text
What is it?
今日はこの本の中から
厳選された内容をお伝えします
Slide 10
Slide 10 text
あじぇんだ
1 自己紹介
2 失われた事実
3 簡単すぎる不整合
4 隠された状態
5 まとめ
Slide 11
Slide 11 text
あじぇんだ
1 自己紹介
2 失われた事実
3 簡単すぎる不整合
4 隠された状態
5 まとめ
Slide 12
Slide 12 text
自己紹介
曽根 壮大（34歳)
株式会社オミカレ 副社長/CTO
• 日本PostgreSQLユーザ会 勉強会分科会 座長
• 3人の子供がいます
• 技術的にはWeb/LL言語/RDBが好きです
そ ね た け と も
Slide 13
Slide 13 text
自己紹介
曽根 壮大（34歳)
株式会社オミカレ 副社長/CTO
• 日本PostgreSQLユーザ会 勉強会分科会 座長
• 3人の子供がいます
• 技術的にはWeb/LL言語/RDBが好きです
そ ね た け と も
Slide 14
Slide 14 text
婚活といえばオミカレ
https://party-calendar.net/
Slide 15
Slide 15 text
あじぇんだ
1 自己紹介
2 失われた事実
3 簡単すぎる不整合
4 隠された状態
5 まとめ
Slide 16
Slide 16 text
No content
Slide 17
Slide 17 text
失われた事実
RDBは、“時間軸と直行するような設計”が大切です。
ですがそれを使ったサービスとしては、
時間軸と直行しないデータ＝履歴を保存することが同じくらい
重要です。履歴の保存を怠ると、
• このデータがどのようにして今の値になったかわからない
• ある日を境に売上データと商品マスタの単価データが合わない
• 払い戻しの処理が特別対応となる
このようなケースと戦うことになります
-- 失敗から学ぶRDBの正しい歩き方 – 第2章 失われた事実
Slide 18
Slide 18 text
失われた事実
失われた事実の例
Slide 19
Slide 19 text
売上id 売上金額 売上日 配送状態
1 29,522 2014-03-31 23:59:59 配送済み
2 6,480 2014-04-01 00:00:00 発注中
︙ ︙ ︙ ︙
名前 値
消費税率 0.05
売上id 商品id 個数 購入者
1 1 3 sone
1 2 3 sone
1 3 3 sone
2 4 3 sone
︙ ︙ ︙ ︙
商品id 商品名 価格
1 SQL実践入門 2,580
2 リーダブルコード 2,592
3 プログラマのためのSQL 4,200
4 データベースリファクタリング 3,000
日付が変わるタイミングで消費税率
を5%から8%に変えることで対応
消費税率*商品.価格*カート.個数=売上金額
カート
売上 設定マスタ
商品
Slide 20
Slide 20 text
失われた事実
4/3に返品があったら？
Slide 21
Slide 21 text
失われた事実
4/3に返品があったら？
↓
該当の商品の個数を減らして、
再計算を実施して売上を更新する
Slide 22
Slide 22 text
売上id 売上金額 売上日 配送状態
1 27,579 2014-03-31 23:59:59 配送済み
2 6,480 2014-04-01 00:00:00 発注中
︙ ︙ ︙ ︙
名前 値
消費税率 0.08
売上id 商品id 個数 購入者
1 1 2 sone
1 2 3 sone
1 3 3 sone
2 4 3 sone
︙ ︙ ︙ ︙
商品id 商品名 価格
1 SQL実践入門 2,580
2 リーダブルコード 2,592
3 プログラマのためのSQL 4,200
4 データベースリファクタリング 3,000
商品id=1の個数を3から2へ
カート
売上 設定マスタ
商品
再計算
Slide 23
Slide 23 text
失われた事実
サポート担当者
「数日前にsoneさんという方が購入された
『SQL実践入門』、1冊だけ返品処理したら
売上がズレるんですけど。」
Slide 24
Slide 24 text
売上id 売上金額 売上日 配送状態
1 27,579 2014-03-31 23:59:59 配送済み
2 6,480 2014-04-01 00:00:00 発注中
︙ ︙ ︙ ︙
名前 値
消費税率 0.08
売上id 商品id 個数 購入者
1 1 2 sone
1 2 3 sone
1 3 3 sone
2 4 3 sone
︙ ︙ ︙ ︙
商品id 商品名 価格
1 SQL実践入門 2,580
2 リーダブルコード 2,592
3 プログラマのためのSQL 4,200
4 データベースリファクタリング 3,000
カート
売上 設定マスタ
商品
売上id=1の返品処理をする場合、
カートの値のみを変更して再計算
すると、本来有るべき値から誤差
が生まれる
Slide 25
Slide 25 text
失われた事実
• 最初の計算
(2,580 × 3 + 2,592 × 3 + 4,200 × 3) × 1.05 = 29,522円
• 返品で個数が、日付で消費税率が変わる
(2,580 × 2 + 2,592 × 3 + 4,200 × 3) × 1.08 = 27,579円
• 本来あるべき計算
(2,580 × 2 + 2,592 × 3 + 4,200 × 3) × 1.05 = 26,813円
Slide 26
Slide 26 text
失われた事実
• 商品名が変わったら？
• 商品の価格が変わったら？
• 購入日と支払日が違ったら？
• 配送状況の過程は？
…etc
Slide 27
Slide 27 text
商品id 商品名 価格
1 SQL実践入門 2,580
2 リーダブルコード 2,592
3 プログラマのためのSQL 4,200
過去の事実と不整合が生まれてしまう
商品id 商品名 価格
1 SQL実践入門 第二版 2,480
2 リーダブルコード 2,592
3 プログラマのためのSQL 4,200
過去の事実(値)が失われる
Slide 28
Slide 28 text
過去の事実(過程)が失われる
配送状況の履歴が無いため
下記の区別がつかない
1. 発注済 → キャンセル → 再発注 → 配送済
2. 発注済 → 配送済み
Slide 29
Slide 29 text
失われた事実
過去の事実は非常時に必要になる
Slide 30
Slide 30 text
アンチパターンを防ぐには？
履歴を保存する
Slide 31
Slide 31 text
アンチパターンを防ぐには？
消費税率 有効日 失効日
0.05 1997-04-01 2014-03-31
0.08 2014-04-01 null
消費税率に履歴を持たせる
・消費税率テーブルを新規に作る
・有効期限をもたせることで、
売上日から消費税率を遡ることができる
・自動切り替えにも対応出来る
Slide 32
Slide 32 text
アンチパターンを防ぐには？
購入時の消費税率の履歴を持たせる
売上id 売上金額 消費税率 売上日 配送状態
1 29,522 0.05 2014-03-31 23:59:59 配送済み
2 6,480 0.08 2014-04-01 00:00:00 発注中
︙ ︙ ︙ ︙ ︙
・売上テーブルに購入時の消費税率を持たせる
・消費税率テーブルがない場合、
この列が無いと返品処理が出来ない
Slide 33
Slide 33 text
アンチパターンのポイント
履歴の保存はトレードオフ
Slide 34
Slide 34 text
アンチパターンのポイント
履歴の保存はトレードオフ
↓
パフォーマンスが落ちる
データの保存とパフォーマンスのトレードオフ
Slide 35
Slide 35 text
アンチパターンのポイント
後からデータを遡りたいときに
事実が失われている設計をしてしまう
Slide 36
Slide 36 text
アンチパターンのポイント
知らない事実を読み解くことは出来ない
Slide 37
Slide 37 text
アンチパターンのポイント
知らない事実を読み解くことは出来ない
↓
失った事実は取り戻せない
Slide 38
Slide 38 text
アンチパターンのポイント
初期設計から事実の履歴については
しっかりと検討すること
Slide 39
Slide 39 text
アンチパターンのポイント
その他の対策方法
1. 最新のレコードを有効なレコードとする
2. 更新、削除もINSERTして、集計する
(イベントソーシング)
詳しくは書籍で！
Slide 40
Slide 40 text
あじぇんだ
1 自己紹介
2 失われた事実
3 簡単すぎる不整合
4 隠された状態
5 まとめ
Slide 41
Slide 41 text
No content
Slide 42
Slide 42 text
簡単すぎる不整合
本書では度々データを守る重要性を説いていますが、
逆に最も簡単にデータを壊す方法は非正規化を行うことです。
しかしながら、パフォーマンスの問題などで
非正規化を利用したくなるケースは実際にあります。
非正規化は劇薬であるということを理解したうえで利用する
のであればいいのですが、最初から検討するのは間違いです。
-- 失敗から学ぶRDBの正しい歩き方 – 第15章 簡単すぎる不整合
Slide 43
Slide 43 text
簡単すぎる不整合
非正規化したいタイミング
Slide 44
Slide 44 text
簡単すぎる不整合
• テーブルを作って正規化をするのが面倒な時
• 外部キー制約によってデッドロックなどが発生してる時
• 正規化によってJOINのコストが高くなり、
パフォーマンスに問題が出ている時
Slide 45
Slide 45 text
簡単すぎる不整合
• テーブルを作って正規化をするのが面倒な時
• 外部キー制約によってデッドロックなどが発生してる時
• 正規化によってJOINのコストが高くなり、
パフォーマンスに問題が出ている時
ダメ！絶対！！
手間を惜しんで大きな技術的負債を産む
Slide 46
Slide 46 text
簡単すぎる不整合
• テーブルを作って正規化をするのが面倒な時
• 外部キー制約によってデッドロックなどが発生してる時
• 正規化によってJOINのコストが高くなり、
パフォーマンスに問題が出ている時
適切に親テーブルにロックを取れば防げる
外部キー制約を外したり、非正規化するのはアンチパターン
Slide 47
Slide 47 text
簡単すぎる不整合
• テーブルを作って正規化をするのが面倒な時
• 外部キー制約によってデッドロックなどが発生してる時
• 正規化によってJOINのコストが高くなり、
パフォーマンスに問題が出ている時
ケース・バイ・ケースといえる難しい問題
しかし多くの場合、正規化したほうがパフォーマンスは有利
Slide 48
Slide 48 text
非正規化の例
postgres=# SELECT * FROM reserve;
id | party_di | 申込者 | 同伴者1 | 同伴者2 | 同伴者3 | 予約日
----+----------+--------+---------+---------+---------+----------------------------
1 | 1 | hoge | fuga | | | 2019-01-14 13:54:14.517217
2 | 2 | foo | bar | hoge1 | hoge2 | 2019-01-14 13:54:14.517217
3 | 1 | hoge2 | fuga | | | 2019-01-14 13:54:14.517217
4 | 1 | test | | test | | 2019-01-14 13:54:14.517217
(4 rows)
-- 同伴者fugaを検索するクエリ
postgres=# SELECT * FROM reserve WHERE
("同伴者1"='fuga' OR "同伴者2"='fuga' OR "同伴者3"='fuga’);
id | party_di | 申込者 | 同伴者1 | 同伴者2 | 同伴者3 | 予約日
----+----------+--------+---------+---------+---------+----------------------------
1 | 1 | hoge | fuga | | | 2019-01-14 13:54:14.517217
3 | 1 | hoge2 | fuga | | | 2019-01-14 13:54:14.517217
(2 rows)
Slide 49
Slide 49 text
非正規化の例
postgres=# SELECT * FROM reserve;
id | party_di | 申込者 | 同伴者1 | 同伴者2 | 同伴者3 | 予約日
----+----------+--------+---------+---------+---------+----------------------------
1 | 1 | hoge | fuga | | | 2019-01-14 13:54:14.517217
2 | 2 | foo | bar | hoge1 | hoge2 | 2019-01-14 13:54:14.517217
3 | 1 | hoge2 | fuga | | | 2019-01-14 13:54:14.517217
4 | 1 | test | | test | | 2019-01-14 13:54:14.517217
(4 rows)
-- 同伴者fugaを検索するクエリ
postgres=# SELECT * FROM reserve WHERE
("同伴者1"='fuga' OR "同伴者2"='fuga' OR "同伴者3"='fuga’);
id | party_di | 申込者 | 同伴者1 | 同伴者2 | 同伴者3 | 予約日
----+----------+--------+---------+---------+---------+----------------------------
1 | 1 | hoge | fuga | | | 2019-01-14 13:54:14.517217
3 | 1 | hoge2 | fuga | | | 2019-01-14 13:54:14.517217
(2 rows)
更新の場合など、バグなどでデータが壊
れることが容易に想像できる
Slide 50
Slide 50 text
簡単すぎる不整合
データは壊れる
Slide 51
Slide 51 text
簡単すぎる不整合
データは壊れる
↓
非正規化はそれをより簡単にする
Slide 52
Slide 52 text
アンチパターンを防ぐには？
データの不整合と速度のトレードオフ
Slide 53
Slide 53 text
アンチパターンを防ぐには？
データの不整合と速度のトレードオフ
↓
非正規化するくらいなら
キャッシュを活用すべき
Slide 54
Slide 54 text
アンチパターンを防ぐには？
RDBMSの責務はデータを守ること
速度の課題はアーキテクチャで解決できる
Slide 55
Slide 55 text
アンチパターンを防ぐには？
キャッシュの例
1. マテリアライズド・ビュー
2. アプリケーションキャッシュ
3. NoSQLなど高速なデータストアの活用
…etc
書籍では解説しています
今日は時間の都合で割愛
Slide 56
Slide 56 text
アンチパターンを防ぐには？
キャッシュの活用は
参照整合性とのバランスで決まる
Slide 57
Slide 57 text
アンチパターンを防ぐには？
しかし多用は禁物
第16章で「キャッシュ中毒」があるので詳しくは書籍で
Slide 58
Slide 58 text
アンチパターンを防ぐには？
非正規化がそれでも必要な時
Slide 59
Slide 59 text
アンチパターンを防ぐには？
非正規化がそれでも必要な時
↓
制約を使う
Slide 60
Slide 60 text
非正規化の例
postgres=# SELECT * FROM アンケート;
id | 回答者 | 好きなデータベース | その他
----+----------+--------------------+--------
1 | soudai | PostgreSQL |
2 | sone | MySQL |
3 | taketomo | OracleDB | SQLite ←不整合
4 | test | SQL Server |
5 | hoge | その他 | Db2
id=3の「その他」列に不正な値
データが壊れるのは正規化出来ていない証拠
Slide 61
Slide 61 text
正規化の例
postgres=# SELECT * FROM アンケート;
id | 回答者 | 好きなデータベース
----+----------+-------------------
1 | soudai | PostgreSQL
2 | sone | MySQL
3 | taketomo | OracleDB
4 | test | SQL Server
5 | hoge | Db2
postgres=# SELECT * FROM データベースの種類;
id | DBの種類 | 回答
----+------------+-------------------
1 | PostgreSQL | PostgreSQL
2 | MySQL | MySQL
3 | OracleDB | OracleDB
4 | SQL Server | SQL Server
5 | DB2 | その他
6 | SQLite | その他
正規化の例
アンケートテーブルの好きなデータベース列は、
データベースの種類テーブルを親とした
外部キー制約を作る
Slide 62
Slide 62 text
アンチパターンを防ぐには？
非正規化したまま
CHECK制約を使ってデータを守る
Slide 63
Slide 63 text
CHECK制約の活用例
-- 想定したデータの登録
postgres=# INSERT INTO enquete ("id", "回答者", "好きなデータベース", "その他") VALUES
(1, 'soudai', 'PostgreSQL', ''),(2, 'sone', 'MySQL', '');
INSERT 0 2
-- 正しくその他を登録する
postgres=# INSERT INTO enquete ("id", "回答者", "好きなデータベース", "その他") VALUES
(3, 'taketomo', 'その他', 'Db2');
INSERT 0 1
postgres=# SELECT * FROM enquete;
id | 回答者 | 好きなデータベース | その他
----+----------+--------------------+--------
1 | soudai | PostgreSQL |
2 | sone | MySQL |
3 | taketomo | その他 | Db2
(3 rows)
非正規化されたテーブル
Slide 64
Slide 64 text
CHECK制約の活用例
postgres=# CREATE TABLE enquete
postgres-# (
postgres(# id serial NOT NULL ,
postgres(# "回答者" text NOT NULL,
postgres(# "好きなデータベース" text NOT NULL,
postgres(# "その他" text NOT NULL CHECK
postgres(# (CASE
postgres(# WHEN "好きなデータベース"!='その他' AND "その他"='' THEN TRUE
postgres(# WHEN "好きなデータベース"='その他' AND "その他"!='' THEN TRUE
postgres(# ELSE FALSE
postgres(# END)
postgres(# );
CREATE TABLE
「好きなデータベースの列」に”その他”が設定された時のみ、
「その他の列」にデータを投入できる
Slide 65
Slide 65 text
CHECK制約の活用例
-- 好きなデータベースがその他の時以外はエラーになる
postgres=# INSERT INTO enquete ("id", "回答者", "好きなデータベース", "その他") VALUES
(3, 'taketomo', 'OracleDB', 'SQLite’);
ERROR: new row for relation "enquete" violates check constraint "enquete_check"
DETAIL: Failing row contains (3, taketomo, OracleDB, SQLite).
-- 好きなデータベースがその他の時に空白でもエラーになる
postgres=# INSERT INTO enquete ("id", "回答者", "好きなデータベース", "その他") VALUES
(3, 'taketomo', 'その他', '');
ERROR: new row for relation "enquete" violates check constraint "enquete_check"
DETAIL: Failing row contains (3, taketomo, その他, ).
CHECK制約で守られる
Slide 66
Slide 66 text
https://soudai.hatenablog.com/entry/2019/01/15/014228
Slide 67
Slide 67 text
アンチパターンを防ぐには？
CHECK制約で確実にデータを守りながら
テーブルを一つ減らせる
Slide 68
Slide 68 text
アンチパターンを防ぐには？
類似例にENUM型がある
Slide 69
Slide 69 text
アンチパターンを防ぐには？
しかしCASE式を使ったCHECK制約は
メンテナンス性が低い
Slide 70
Slide 70 text
アンチパターンを防ぐには？
正規化出来るなら正規化したほうが良い
Slide 71
Slide 71 text
No content
Slide 72
Slide 72 text
Tips
なんとMySQL 8.0.16から
CHECK制約が来ます！
Slide 73
Slide 73 text
アンチパターンのポイント
正規化出来るなら正規化したほうが良い
Slide 74
Slide 74 text
アンチパターンのポイント
正規化出来るなら正規化したほうが良い
↓
RDBは正規化に始まり、正規化に終る
Slide 75
Slide 75 text
アンチパターンのポイント
非正規化の技術的負債の利子は重い
Slide 76
Slide 76 text
アンチパターンのポイント
非正規化の技術的負債の利子は重い
↓
代替手段があるのでそれを念頭に置き
論理設計を行うことが大切
Slide 77
Slide 77 text
https://soudai.hatenablog.com/entry/2018/08/31/222107
正規化の話
Slide 78
Slide 78 text
https://builderscon.io/tokyo/2018/session/ddba9bd5-819e-489e-9123-04d2291d506e
動画もあるよ
Slide 79
Slide 79 text
非正規化と履歴データ
非正規化と履歴データは違うの？
Slide 80
Slide 80 text
非正規化と履歴データ
非正規化と履歴データは違うの？
↓
履歴データは非正規化に見えるが
非正規化ではない
Slide 81
Slide 81 text
非正規化と履歴データ
別々の事実の積み重ねが履歴データ
非正規化は事実の重複
Slide 82
Slide 82 text
あじぇんだ
1 自己紹介
2 失われた事実
3 簡単すぎる不整合
4 隠された状態
5 まとめ
Slide 83
Slide 83 text
No content
Slide 84
Slide 84 text
隠された状態
RDBに状態を持たせるのはたいへん危険です。
第2章「失われた事実」や第5章「フラグの闇」でも、RDB
に事実のみを保存することの大切さと難しさをお話しました。
なぜ複数の章に渡って強調してきたかというと、
隠された状態には多くの罠が潜んでいるからです。
本章ではその理由と、それによって引き起こされる問題に
ついて説明します。
-- 失敗から学ぶRDBの正しい歩き方 – 第7章 簡単すぎる不整合
Slide 85
Slide 85 text
隠された状態
データに状態を持たせることは危険
Slide 86
Slide 86 text
user_idを見てユーザを判断
if($this->is_admin($user->user_id))
{
// 管理者用の処理へ
}
// user_id の先頭が 9 だった場合は管理者
function is_admin($user_id)
{
$role_id = mb_substr($user_id, 0, 1);
return ($role_id == 9) ;
}
idに状態が隠れている
Slide 87
Slide 87 text
閲覧のみユーザ用の処理を追加
$role_id = $this->get_role_id($user->user_id);
if ($role_id == 9) {
// 管理者用の処理へ
} elseif ($role_id == 8) {
// 閲覧のみユーザの処理へ
}
function get_role_id($user_id)
{
return $role_id = mb_substr($user_id, 0, 1);
}
仕様追加の度に複雑に
Slide 88
Slide 88 text
隠された状態
県番号(2桁) 部門ID(3桁) 支店ID(4桁)
（例：330010012）
よく見る例
Slide 89
Slide 89 text
隠された状態
今の会員数と管理者の人数って何人？
Slide 90
Slide 90 text
隠された状態
今の会員数と管理者の人数って何人？
↓
検索時にuser_idを分割するSQLが必要
複雑+INDEXも効かないので即答できない
Slide 91
Slide 91 text
隠された状態
意味を含んだID
データベースリファクタリングでは
スマートカラム呼ばれるアンチパターン
Slide 92
Slide 92 text
隠された状態
ソースコードやクエリからは
user_idだけでは意味がわからない
Slide 93
Slide 93 text
似たようなアンチパターン
• EAV
（エンティティ・アトリビュート・バリュー）
• Polymorphic Associations
（ポリモーフィック関連） SQLアンチパターン
本著でも説明している
Slide 94
Slide 94 text
まだ読んでないなら絶対読んだほうがいい
本著はSQLアンチパターンを読んでる前提の説明も多い
Slide 95
Slide 95 text
隠された状態
コードやデータから見えない状態の辛さ
Slide 96
Slide 96 text
隠された状態
コードやデータから見えない状態の辛さ
↓
運用コストが激増する
Slide 97
Slide 97 text
アンチパターンを防ぐには？
正規化をする
＋
事実を保存する
Slide 98
Slide 98 text
アンチパターンを防ぐには？
事実のみを保存する
Slide 99
Slide 99 text
アンチパターンを防ぐには？
IDとはidentification
Slide 100
Slide 100 text
アンチパターンを防ぐには？
IDとはidentification
↓
識別できる一意の値
以上の意味を持たせてはいけない
Slide 101
Slide 101 text
会員id 名前
900001 曽根 壮大
900002 曽根 徠楽
100003 曽根 煌楽
100004 曽根 朔楽
idから権限の責務をカラムに分割する
会員id 名前 権限
1 曽根 壮大 管理者
2 曽根 徠楽 管理者
3 曽根 煌楽 一般ユーザ
4 曽根 朔楽 一般ユーザ
意味を含んだIDの改善例
Slide 102
Slide 102 text
アンチパターンを防ぐには？
正しく正規化をすること
Slide 103
Slide 103 text
アンチパターンのポイント
• データに複数の意味を持たせない
• 1つのデータの責務を小さくする
• 常に状態が見えるようにするために
事実のみを保存する
Slide 104
Slide 104 text
アンチパターンのポイント
交差テーブルをちゃんと作る
Slide 105
Slide 105 text
アンチパターンのポイント
交差テーブルをちゃんと作る
↓
JOINのコストを最初から危惧しない
失われた事実と同じく、パフォーマンスの問題は
別の方法で対応する
Slide 106
Slide 106 text
アンチパターンのポイント
正規化出来るなら正規化したほうが良い
めちゃくちゃ大切なことなので何度も言います
Slide 107
Slide 107 text
おまけ
Slide 108
Slide 108 text
おまけ
Slide 109
Slide 109 text
あじぇんだ
1 自己紹介
2 失われた事実
3 簡単すぎる不整合
4 隠された状態
5 まとめ
Slide 110
Slide 110 text
まとめ
“愚者は経験に学び、賢者は歴史に学ぶ。”
--オットー・ビスマルク
Slide 111
Slide 111 text
まとめ
データベースの寿命は
アプリケーションよりも長い
Slide 112
Slide 112 text
まとめ
データは失うと取り戻せないし、
情報はデータが無いと作れない
Slide 113
Slide 113 text
まとめ
他人の失敗から学び、
正しくRDBを使いこなす
Slide 114
Slide 114 text
まとめ
今、あるデータベースと向き合うには？
Slide 115
Slide 115 text
まとめ
今、あるデータベースと向き合うには？
↓
自分たちで直すしかない
Slide 116
Slide 116 text
https://builderscon.io/tokyo/2017/session/c8f36693-32aa-4bf1-816a-4966f3859926
Slide 117
Slide 117 text
まとめ
諦めず、仕組みで解決していく
Slide 118
Slide 118 text
まとめ
諦めず、仕組みで解決していく
↓
仕組みは技術力で解決できる
Slide 119
Slide 119 text
まとめ
数冊の本を読むだけで
充分な知識がつくのがRDB
Slide 120
Slide 120 text
まとめ
技術で問題を解決していく
Slide 121
Slide 121 text
まとめ
技術で問題を解決する
↓
解決までの歩んだ轍が道になる
Slide 122
Slide 122 text
まとめ
RDB THE Right Way
Slide 123
Slide 123 text
まとめ
RDB THE Right Way
↓
あなたの道を歩くのはあなた自身
Slide 124
Slide 124 text
まとめ
自分自身で改善のサイクルを回していく
Slide 125
Slide 125 text
まとめ
技術で解決した問題の価値が
エンジニアの価値
Slide 126
Slide 126 text
まとめ
自分自身で問題を解決していきましょう
Slide 127
Slide 127 text
ご清聴ありがとうございました