20190621冲搁顿叠惭厂の痴滨贰奥を使って搁补颈濒蝉のデータアクセスをいい感じにする【银座搁补颈濒蝉＃10】
0 likes10,216 views
银座搁补颈濒蝉＃10で発表した搁补颈濒蝉で搁顿叠惭厂の痴滨贰奥を使ってデータアクセスをいい感じにする方法のスライドです。
![[Pgday.Seoul 2017] 2. PostgreSQL? ?? ??? ?? ??? - ???](https://cdn.slidesharecdn.com/ss_thumbnails/pgday-171106040432-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Similar to 20190621冲搁顿叠惭厂の痴滨贰奥を使って搁补颈濒蝉のデータアクセスをいい感じにする【银座搁补颈濒蝉＃10】 (20)
![[RubyMotion LT] nitronに見るiosアプリ開発の未来](https://cdn.slidesharecdn.com/ss_thumbnails/rubymotionltnitronios-120808215226-phpapp01-thumbnail.jpg?width=560&fit=bounds)
20190621冲搁顿叠惭厂の痴滨贰奥を使って搁补颈濒蝉のデータアクセスをいい感じにする【银座搁补颈濒蝉＃10】
- 1. RDBMSのVIEWを使って データアクセスをいい感じにする 森 雅智 / @morimorihoge 2019/06/21 銀座Rails#10 1 スライド＆解説は別途公開するので気楽に聞いてください
- 2. About Me ? 森 雅智? @morimorihoge ? Railsの受託開発チームをやってたり、週1大学非常 勤でWeb開発を教えてたりします ? Ruby/Rails歴は8年くらい。Web開発は14年くらい ? TechRachoという技術Blogをやってます ? https://techracho.bpsinc.jp ? 「週刊Railsウォッチ」ほか、ぜひご意?お待ちしてます? 2
- 6. RDBMSのVIEW機能 ? `CREATE VIEW`構文で作成できるRDBMSの標 準機能の一つ ? 物理的なテーブルは作成せず、SELECT文への エイリアスを作れるイメージ ? 作成したVIEWには通常のテーブルと同じよう にSELECTできる ? 条件付きでUPDATEも可能 ※本発表は基本的にRails 5.2.3 + PostgreSQL 11で検証していますが、 データ型等のRDBMS依存のもの以外はほぼそのまま動くと思います 6
- 7. こんな感じ 7
- 9. VIEWの特徴 ? RDBMSの標準機能であること ? SQL89からあるので、メジャーRDBMSなら使える ? 一度作ったVIEWはTABLEと同じようにSELECT することができる ? 大事なことなので二回書きました 9
- 13. ありそうな要件その1 ? メール認証済みユーザーだけを取得したい ? 具体的には confirmed_at IS NOT NULL 13
- 14. 一般的なRails Way: scope Modelにscopeを記述 scoped chainを使う 14
- 15. これでOK? 15
- 16. scopeの弱点 ? scoped chainが増えてくると付け忘れなどのミスが 発生しやすい ? メールアドレス確認フラグ、BANフラグ、退会済みフラグ、 etc… ? 特にアプリが大きくなってから仕様追加したときには特に チェック範囲が膨大になりがち ? 「ほとんどいつも使う」scopeの扱い問題 ? 毎回`.confirmed`つけるのが正直だるいし忘れると事故る ? default_scopeという手もあるが、newするときに影響する し、unscopedは注意しないと事故る 16
- 18. scope代わりのfilterとしてVIEWを使うテクニック ? 利点 ? 複雑化したscoped chain hellから脱却できる ? 将来的に「有効なユーザー」の定義が変わっても、 VIEWのmigrationだけで対応できる（もしunscoped するコードがあっても安心） ? default_scope嫌い派もにっこり? ? 欠点 ? 複雑なアプリケーションロジックが必要なscopeでは置 き換えが難しいことがある 18
- 20. 一般的なRails Wayだと? ? Viewのコードで <%=@user.XXX if @user.is_public_XXX %> ? 絶対事故る自信があるのでプロトタイピング以外ではオススメしない ? ModelをViewに渡すときにDecorator(Presenter)系のGemで ラップする?Draper / ActiveDecorator等 ? 既に利?していれば良いが、プロジェクト全体で使っていない場合は Decorator通し忘れてしまったりする危険も ? そもそもActiveRecordは`SELECT *`するため、非公開情報を 含むかもしれないARオブジェクトの取り扱いには注意が必要 ? inspectすれば?えてしまうので、情報によってはログ出?などにも配 慮が必要になる 20
- 23. 特定?途向けにデータを加工したVIEWを使うテクニック ? 利点 ? 加工前の情報はRails側のメモリにすら乗らないので安全確実 ? 大規模CMSなどで管理画??のRailsアプリとフロント?アプリが分離 している場合などに良い ? SQL関数を使うことで、一部のデータ変換をRDBに任せることも できる ? Rails側のCPUやメモリを節約したい場合には良い ? 非RailsシステムのDBを参照する場合にRails Wayな名前に変 換して使うこともできる ? SIer業界の謎のコード連番カラム名みたいなやつもばっちり（更新も するならalias_attributeの方がいいかもしれない） ? 欠点 ? 機能ごとにVIEWを作り続けているとVIEW沼に陥る可能性がある ? 複雑なSQLは読み書きが難しくなってくるので、プロジェクト チームのSQL熟練度によってはメンテが俗?化する 23
- 25. Rails Wayだと???? ? mergeやjoinsを使って条件を組み?てていくのが基本 ? 1-3テーブルくらいまでならなんとかなる ? OUTER JOINを含んだ関連の遠いテーブルJOINなども必要に なってくるととてもつらくなる（主観です） ? Arelじゃなくて生SQL書かせて?ってなる ? Query Object作ったり集計?クラス作ったり ? 検索だとRansackがお手軽? ? 単純なhas_manyくらいまでならなんとかなる ? SELECT元が複雑になると、ransackable_scopesとかを使っ ていく必要があり、お手軽感が薄まっていく、つらい 25
- 28. 多数のテーブルをまとめた検索?VIEWを使うテクニック ? 利点 ? VIEWさえできていればRailsエンジニアは内部構造を気にせず検索?参 照できる ? 歴史的経緯により複雑怪奇になってしまった商品テーブルなどにとても有効 ? Ransackをほぼそのまま使えたりして最高 ? 開発難易度が下がるので正しいVIEWを作るところだけ強い?がやれば、あとは開 発経験が浅めのエンジニアでも対応できる ? 取得したオブジェクトはAR::Relationなので、AR拡張Gemとの相性が 良い ? AR::Base.executeしたデータと違い、ページングや参照が「普通の ActiveRecord」の使い方ができる ? 欠点 ? VIEWを作るのにそれなりにSQLに?けたエンジニア（いわゆるDBA）が 必要 ? VIEWの定義によっては重いクエリになるのでDBサーバーの負荷が想定 外に増えることがある 28
- 29. VIEWを使うときの注意点 ? 定義済みVIEWの参照はGem不要だが、migration管理には scenicが必要（次のページで） ? `CREATE VIEW`は生SQLのため、Railsのデータ変換層を通ら ない。timezoneの扱いに要注意 ? アプリケーションロジックがVIEW定義の中に?るので、何を Railsで決めて何をVIEWに逃がすかのプロジェクトポリシが大事 ? `SELECT *`のカラムリストはVIEWを作成したタイミングで展開 されるので、元テーブルに更新があればVIEW定義も更新する必要 がある ? 少なくともPostgreSQL 11ではそうでした ? 参照専?のVIEWであれば、#save不可にしておくと良い ? trueを返すreadonly?メソッドを定義する（scenicのREADME参照） 29
- 30. Scenic Gem ? Rails標準のmigrationシステムはVIEWのmigrationに対応し ていないため、migration管理するならこれが必須 ? 使い方は難しくないのでREADME読めばわかるはず ? https://github.com/scenic-views/scenic Generator #update_view の追加 30
- 31. VIEW + Railsの可能性 ? 他の利??途 ? CTE使ってRECURSIVEな階層データを参照するVIEWを作ったり ? FDW組み合わせて複数データソースを横断検索したり ? Redashとか使えって話でもありますが ? GRANTと組み合わせてシステム間DB共有をより安全にしたり、 マルチテナントシステムの多層セキュリティの一環にした り??? ? MATERIALIZED VIEWを使って複雑なクエリを高速検索したり うはー 夢が広がりんぐ 常に良い設計になるとは限らないが、?法??量を守れば Railsのコードの複雑化を回避する手段になる 31
- 32. 最後に ? 多分時間?りなくて?々端折ったので、じっくり?直 したい方はTechRachoの記事も読んでみてください ? https://techracho.bpsinc.jp ? ※本発表と同時に記事公開予定です ? 懇親会でも気軽にお声かけ下さい 32