RDBアンチパターン // Speaker Deck

PHPカンファレンス2016の資料です http://phpcon.php.gr.jp/2016/

[vanbraam]

s/デットロック/デッドロック/gだし,s/excluded lock/exclusive lock/gでは;消費税の例,その非正規化はありだが万能ではない.例:新税が追加されたら?;DBMS実装固有の知識よりまず関係代数と並列処理の基礎を学ぶ方がいいと思う

[atsushifx]

削除フラグについては、いかのスライドを見るべき http://www.slideshare.net/t_wada/ronsakucasual

[rgfx]

ORMよりはSQLベタ書きしたさしかない。（編集履歴テーブルに、削除した行の内容をjsonで格納しておくとかかねえ。

[Dai_Kamijo]

・データベースの寿命は、アプリケーションよりも長い ・シンプルな設計は全てに勝る ・データの寿命はコードよりも長い ・一度作ったDBは消せない→設計が大事 ・データベースの死はサービスの死 ・RDBの知識は寿命が

[maraigue]

"現状ではORMはインピーダンス・ミスマッチを解決するための存在であってRDBの完全な抽象化ではない" "レコードに状態を持たせると危険" "データベースの死はサービスの死"

[Chisei]

TL に流れてきたので見た。

[tyru]

いい加減買おうかな

[oh240]

本当に経験がないので、こういうのは非常に参考になる。

[golden_eggg]

ええ話や

[miu_suke]

かくありたい。次の案件では絶対に…って100年ぐらい言ってる

[naopontan]

事実を保存せよ。状態は保存しないほうがいいよ.事実の履歴を保存せよ。

[kaipu1224]

この辺の話、業務系だと結構普通の事だと思う。

[hyottokoaloha]

状態が変化した時間を保存するのはよくやる

[slash_01]

素晴らしい資料だ

[nureha]

わかる！とかそうなんだよ！ってなっても最終的に現場でみんなを納得させられないのはやっぱり自分の理解が浅いってことなんだろうな・・・

[mak_in]

こういうのがあってこだわりたい、けど書くの簡略化したいから個人的にはMicro-ORMが好き。

[pekeponnn31]

あー、今の現場の人に読んでほしい。 何でもかんでもdelete_flag

[raimon49]

ステータスを表すカラムではなくレコードの追加で歴史を作る。

[key_amb]

「ORMに頼りすぎない。ロックはパフォーマンスとトレードオフ。RDBはいいぞ」

[progrhyme]

「ORMに頼りすぎない。ロックはパフォーマンスとトレードオフ。RDBはいいぞ」

[paulownia]

状態

[khei-fuji]

このへん興味深かった "隠された状態"

[torinky]

RDBアンチパターン

[megamouth]

削除フラグが害悪なのは同意するけど、状態保存しちゃダメとまで一般化していい話なのかな？当初想定以上のスケーラビリティまでアプリケーション側に求めるのもちょい酷な気もするけどね。DBAさんらしいご意見ですな

[SWIMATH2]

RDBの機能と他のツールによる制約をちゃんと知ろうという話？ORMの話がタメになる

[watarum]

ぺちぱーに知ってほしい。