app/mailersディレクトリ以下にファイルを作成し、ActionMailer::Baseを継承する。 class UserMailer < ApplicationMailer end 作成したmailer内でメソッド(アクション)を定義 class UserMailer < ApplicationMailer def welcome_email @user = params[:user…

app/mailersディレクトリ以下にファイルを作成し、ActionMailer::Baseを継承する。 class UserMailer < ApplicationMailer end 作成したmailer内でメソッド(アクション)を定義 class UserMailer < ApplicationMailer def welcome_email @user = params[:user…

class Catalog < ActiveRecord::Base enum status: [published: 0, unpublished: 1, not_set: 2] end catalog.published! # catalog.status = 0 になる 参考 https://qiita.com/punkshiraishi/items/799bef63607e03262644

複数のクラスにまたがる一連の手続きを定義する。 app以下にserviceディレクトリを作りファイルを置く。

複数のクラスにまたがる一連の手続きを定義する。 app以下にserviceディレクトリを作りファイルを置く。

特定のテーブルに対する操作（挿入・更新・削除）を契機として、あらかじめ定義された処理を自動的に実行する機能のこと。 トリガーの基本的な目的は複数テーブル間のデータ整合性を確保することにある。 DB側にもロジックを持たせることになるので保守性、…

参考 https://n350071.com/factorybot-trait-has_many-has_many/

複数の目的に利用されるカラム は作るべきではない。 属性名、値のようなカラム を作り属性名にさまざまな種類の項目が入る場合、制約やデータ型を正しく設定できない。

カラム の値には複数の意味を持たせてはいけない。 例えば、idカラム には一意を識別するための意味しか持たせてはいけない。 会員テーブルのidカラムに会員の種類を識別するような意味を持たせてはいけない。

attrの場合はdata-target属性の値が#modal_other_group_duplicate_deleteに変更されるのに対して、propの場合は変更されない。 propはキャッシュに対して操作が行われる為か属性の値が変更されなかった。 $("#delete_button").attr('data-target', '#modal_o…

delete_flagの欠点 SQLの複雑度が増す（検索時にwhere delete_flagを入れる為） 複合インデックスを使用しなければならなくなる。（検索時にwhere delete_flagを入れる為） UNIQUE制約が使えなくなる。 カーディナリティが低くなる。

テーブル内のデータを全て削除する。 テーブルを一旦削除してから再構築するのでdeleteでデータを全て削除するより高速。 TRUNCATE TABLE (表名); 参考 https://www.earthlink.co.jp/engineerblog/intra-mart-engineerblog/2680/

traitを指定する際はfactoryで定義したモデル名の次（第二引数）に渡す。 create(:customer, :with_master, user_id: user.id) 以下のように順番を入れ替えるとエラーになる。 create(:customer, user_id: user.id, :with_master)

inner join の際、結合条件をandで指定できる。 ここで不等号を使うことができる。 その日までの集計を日毎に行う場合などに使える。 参考 https://gotto50105010.hatenablog.com/entry/2019/02/17/140404

組織図のような入れ子構造をDBで表現する際には入れ子集合モデルが有効。 一つのレコードに左端と右端のカラムを持たせて親レコードの左端と右端の値の中に子レコードの左端と右端の値が入るようにすればこれを表現できる。 データの更新の際に関しては、左…

SQLの結果をテーブルとして保持する仕組み。 マテリアライズドビューを利用すると、データベースでSELECTした結果をテーブルとして保持できるため、複雑な集計処理の高速化やデータ整合性の確保を簡単に実現しつつ、SELECT処理を効率的に行うことができる。 …

InnoDBの場合、基本的には前回インデックスが更新が行われてから以下の条件で自動的にインデックスの最適化が行われます。 テーブル行数全体の 1/16 が更新される 20億行以上更新される ですので通常はコマンドを実行する必要はありません。 optimize table …

オプティマイザは統計情報をもとにアクセスパスを決定している。 この統計情報はデータが更新される度に少しずつ変化していく。 そのため定期的に統計情報を更新しなければならない。 これはDBMSがデフォルトで勝手に実行しているが手動でいつ行うかを決める…

subject { Customer.new_by_entity(entity) } its(:house_company_code) { is_expected.to eq entity.house_company_code } itsで expect(Customer.new_by_entity(entity).house_company_code).to eq entity.house_company_code と同じことになる 参考 http:…

照合順序 文字コード＋言語名＋比較法で構成される 例） utf8mb4_unicode_ci sql実行時にcollateを指定することでオーバーライドすることもできる。 その場合文字コードが違う場合はオーバーライドできない。 unicode の方はあいまいな照合が可能で全角、半…

実行したsqlが表示される。 参考 https://takami-hiroki.hatenablog.com/entry/20101027/p1

具体的には、フレームワークの読み込み＆gemの読み込みが終わったタイミングで読み込まれます。 開発環境・テスト環境・本番環境全てで読み込まれます。 gemを入れるとそのgemの設定ファイルが追加されたりします。自分で.rbファイルを作成して追加すること…

ページが表示される際にどこにどのくらいの時間がかかっているかを表示してくれるgem 参考 https://nishinatoshiharu.com/usage-rack-mini-profiler/

railsにはページキャッシュ、アクションキャッシュ、フラグメントキャッシュがある。 ページキャッシュ、アクションキャッシュはあまり使われずgemとして切り出されてdefaultでは使用できない。 参考 https://postd.cc/the-complete-guide-to-rails-caching/

クエリを生成するための条件を持っておいて必要に応じてSQLクエリを実行する。 その結果からオブジェクトを作成してくれる。 参考 https://spirits.appirits.com/doruby/8831/

駆動表と内部表はオプティマイザの判断により入れ替わる。 SELECT count(*) FROM `cars` INNER JOIN `parts` ON `parts`.`car_id` = `cars`.`id` 上記sqlでも場合によってpartsが内部表になることもある。 explainで最初の行が駆動表。 参考 https://enterpr…

joinsは内部結合 どちらかのテーブルにしかないレコードは除外される

join先のテーブルでwhere句を使いたい時はeager_loadを使う 参考 https://love-and-geek.caraquri.com/back-end-rails-slow-query/

共通化せず、分けることが重要です。同じ操作の箇所はそこを関数化することで、重複した処理を書かずに済みます。 無理に共通化しようとすると一つのメソッドで書けるかもしれないが複雑になりがちで機能追加などの際にメンテナンス性が悪くなる。 参考 http…

resources(またはresource)だけを使用して書くと規定の7つ以外のアクションを書くことがなくなり以下のようなメリットがある。 →コントローラーの肥大化を防げる。 →コントローラーの責務を明確にできる。 →routingに統一感が出て可読性が上がる。