![2. データの整合性チェック
class User < ApplicationRecord
# 必須
validates :name, presence: true
# 必須かつカタカナのみ
validates :kana, presence: true, format: {with: /A[ァ-ー]+z/}
# 必須かつ3?20文字以内
validates :code_name, presence: true, length: { in: 3..20 }
# 必須かつ一意である
validates :email, presence: true, uniqueness: true
end
user = User.new
user.valid? # => false](https://image.slidesharecdn.com/orm-170408084020/85/Orm-16-320.jpg)
翱谤尘との付き合い方
- 4. ORMとは？ ● Object-relational mapping(オブジェクト関連マッピング) ● データを取得したタイミングで、データを元にオブジェクトを生成する。 ● 特定のテーブルとクラスが1対1になっていて、そのクラスのメソッド経由でデータ を取得する（Rubyで使われるORMのActiveRecordなどの場合）
- 5. ORMの利点 1. 異なるDBの違いを吸収してくれる 2. SQLを書かなくてもいい（自動生成してくれる） 3. プレイスホルダーによってエスケープをよしなにしてくれる （SQLインジェクション対策）
- 6. ORMのよくない点 1. 遅い（オブジェクト生成） 2. リソースを食う（メモリ消費が大きい） 3. 特定のDBの便利な機能が使えない 4. 複雑なデータを取得しようとするとSQLより難しい 5. 頑張れば1回で取得できるデータなのに、 何度もクエリを発行するような処理を書いてしまいがち。 結果、さらに遅くなる…。 6. ORMでのデータ取得にこだわりすぎる人が現れる
- 7. そもそも論として…SQL派の人へ 1. 速いのは正義ですが、そんなにスピード求められますか？ ORMでも高速にデータ取得する方法は準備されてたりしますが。 （マッピングせずに配列として取得するとか） 2. 特定のDBの機能、頻繁に使いますか？ 3. 翱搁惭のプレイスホルダーを利用したエスケープって便利じゃないですか？
- 8. そもそも論として…ORM派の人へ 1. データベース自体の変更ってよくありますか？ （ビジネスがかなり拡大してきたらありえるとは思う） 2. なにがなんでもORMで処理しなければならないことってありますか？ 3. ORMを使っててもDB制約は利用しますよね？ （ユニーク制約、NOT NULL制約、Indexなどなど…） 4. クエリ発行回数は意識してますか？ DBへのアクセス数が多いのは怠慢ですよ！（ウッ…
- 9. どうして二元論にしようとするのか？ 1. ORMかSQLのどちらかに統一されてないと気持ち悪いですか？ 2. 目的は、いいプロダクトを作ること 3. ORMを使ったほうが便利なものはORMで 4. SQLを書いた方が楽な場合はSQLで 5. とはいえ、9割方ORMを使ってます
- 10. ORMの利点(ActiveRecord) 1. 直感的なデータ検索 2. データの整合性チェックが容易 3. コールバックによる連携更新 4. 取得したデータがオブジェクトなのでさらに直感的に 5. 変更に強い 6. テスト可能になる 7. テーブル定義の変更の履歴が残る
- 12. SQLのよくない点 1. 直感的ではない 2. SQLがわかる人しか書けない 3. テストが（簡単には）できない 4. データの整合性チェックが（簡単には）できない 5. 変更に弱い 6. 作者の意図を表現できない（ORMだとメソッド名で表現できる）
- 13. ORMの利点(ActiveRecord) 1. 直感的なデータ検索 2. データの整合性チェックが容易 3. コールバックによる連携更新 4. 取得したデータがオブジェクトなのでさらに直感的に 5. 変更に強い 6. テスト可能になる 7. テーブル定義の変更の履歴が残る
- 14. 1.直感的なデータ検索(ActiveRecord) user = User.find 1 # => idが1のUserを取得する user = User.find_by email: ‘admin@example.com’ # => メアドでUserを取得 users = User.admin.where(created_at: 1.month.ago..Time.zone.now) # => 1ヶ月以内に作られた管理者を取得 articles = Article.joins(:user).merge(User.normal).published .order(updated_at: :desc).limit(10) # => 一般ユーザーが作った公開中の記事を更新日降順に10件取得 soft_destroyed_comments = Commnet.only_soft_destroyed # => 論理削除されたコメントを取得
- 15. 1.直感的なデータ検索(多少複雑なJOIN編) User.joins(“INNER JOIN (#{Comment.group(:user_id).select(“user_id, COUNT(user_id)”).to_sql}) AS comments ON users.id = comments.user_id”).select(“*”) # => ユーザー毎のコメント数を含むユーザー一覧を取得 複雑なJOINもto_sqlを使ってSQL化(サブクエリ化)してしまえば、 そこまで難しくない。 （INNER JOINとONを書くのがダサイという意見は当然ある）
- 16. 2. データの整合性チェック class User < ApplicationRecord # 必須 validates :name, presence: true # 必須かつカタカナのみ validates :kana, presence: true, format: {with: /A[ァ-ー]+z/} # 必須かつ3?20文字以内 validates :code_name, presence: true, length: { in: 3..20 } # 必須かつ一意である validates :email, presence: true, uniqueness: true end user = User.new user.valid? # => false
- 17. 2. データの整合性チェック class User < ApplicationRecord end class Group < ApplicationRecord end class UserGroup < ApplicationRecord # 1つのグループに1人の人が複数登録されるのを防ぐ validates :user, presence: true, uniqueness: { scope: group_id } end user_group = UserGroup.new(user_id: 1, group_id: 1) user_group.save # => true user_group = UserGroup.new(user_id: 1, group_id: 1) user_group.save # => false
- 18. 6. テスト可能 ● データの整合性チェック、本当に正しいものが定義できてる？ ● 複雑な条件でのみ登録?更新できるパターンの検証は人力では難しい 例１）1人のユーザーが所有できるモンスターの上限は3000。 3001番目が登録されたら…？ 例２）メールアドレスの重複登録はできないが、退会済ユーザーの メールアドレスは再登録できるように。 例３）A,B,Cが登録されてようやくDが登録できる ● データの取得に関しても同様に、正しいデータが取得できてる？ 例１）前回のログイン以降に更新されたデータ件数を取得 例２）公開フラグのあるデータのみを取得できているか？ ユニットテストで検証が可能！（RubyならRspecやMinitestなど） ※SQLも取得結果はプログラミング言語側でテスト可能
- 19. 翱搁惭の検証と顿叠制约の利用
- 21. 翱搁惭と顿叠制约で冗长では？
- 23. ORMの利用シーン 1. Webアプリケーションのいたるところで利用 2. 不具合の調査(rails console、デバッガ) 3. 頻繁に変更がありうる処理
- 24. SQLの利用シーン 1. データ分析（主に集計。UNIONしたりとか、Window関数使うとか） 2. ORMで表現するのが難しい処理（whereの条件が複雑とか） 3. 灭多に変更がない処理
- 25. まとめ 1. 適材適所で付き合おう 2. ORM使ってたとしてもDBの勉強は必要 3. 翱搁惭と顿叠制约のダブルチェックで安全なデータ管理