可読性が悪く、メモリ効率では誤差。スキーマにこだわるべき。&quot;キー&quot;ShareNoSQLkeyredis2014-10-27プログラミングRailsでのtimezoneをUTCにするRailsで時間情報を扱う場合、JSTだとグローバル対応した時にいろいろ面倒。データ情報は全てUTCで扱って、取得するときのみJSTに変換するようにする。注意点としては以下の通り。modelでdatetime型に情報を渡す場合、ActiveSupport::TimeWithZone型で渡しておく。modelでdatetime型から情報を受け取る場合、JST時間に変換する。現在時刻を扱う場合、Time.nowは使わずにTime.zone.nowを使う。設定日本在住の場合、初期設定時は以下のようになっている。RDSUTCOSJSTHomebrew(PostgreSQL)JSTRails、Heroku、RDS、OS辺りは特に設定はいらない。自分のPCにpostgreSQLをインストールした場合はtimezoneをUTCに設定しておく。例以下のplaysテーブルを例として考える。modelを作成する。play1.played_at.in_time_zone(&apos;Tokyo&apos;)endShareJSTRailsRails4RubyTimeZoneUTCdatetimetimestamp時間2014-10-23プログラミングhas-oneが動作しなかったのでclass_nameを追加した次のようなmodelがある。:destroyendhas_manyはいいんだけど、has_oneはこのままだと動作しない。class_nameを追加する。:destroyendSharehas_onemodelrailsrails4ruby2014-10-22プログラミングrailsに外部キー制約を追加してみたデータベースに関して調べることって、業務的な側面から、わかりづらい単語や言葉ばっかり使って理解しづらいよね。誰でも分かるように説明するのがプロなんだよなぁ。プログラミングそのものに関してはそうでもないんだけどな。身近にあるもので例えてみる。key)とはリレーショナルデータベース(RDB)で、テーブルのある列に、別のテーブルの特定の列に含まれる項目しか入力できないようにする制約。e-words.jpうん言葉で言ってもわかりづらいw図で表してみる。この左側の赤いやつが外部キー。別のテーブルの主キーを指してるでしょ?また、別のテーブルの主キーは参照キーと呼ばれる。外部キーの問題って?じゃあもし外部キーの参照先が更新されたり、削除されたらどうなるか。2の状態ではあるけど、指している場所にデータがない。どこ指してるかわからない。参照整合性が取れない。いわゆる迷子レコードになる。外部キー制約を使うかじゃあこれをどうするかというと、以下の2通りの方法を行う。アプリ側で監視する外部キー制約を使う普通は1を使うんだけど、1にも以下の問題点がある。スクリプトを全ての参照に対して行う必要があるチェックを毎日、何回も実行しなければならない参照が壊れていた場合でも修正できるかはわからないこの位の小さいテーブルだったらスクリプトでもいいけど、親、子、孫...と何個も組み合わさっているとチェックできるかは怪しい。そこで2の手法、外部キー制約を使う。ちなみに、これはオライリーのSQLアンチパターンに外部キー嫌いって項目で書いてある。この本、結構面白くてSQLでダメなことが一通り書いてある。DB設計時にこれどうすればいいんだろうってのが結構解決する。俺でも分かったから、初心者でもわかりやすいと思う。Inheritance、通称STI)にはお世話になりました。ON)にそれぞれ設定できる。外部キー制約は主に4種類。DEFAULTとかもあるけど、今回は割愛。ACTIONとRESTRICTは同じ。ACTION)子が外部キーを持っていた場合、その親の操作をさせなくする。CASCADE子が外部キーを持っていた場合、その親が更新や削除したら、子もそれに追従する。NULL子が外部キーを持っていた場合、その親が更新や削除したら、子にnullを代入する。Railsではどうなの?RailsはActiveRecord経由で操作、つまりmodelに書く。制約名を追加するだけでいい。これはActiveRecord経由で操作するものだけにしか効果が無いつまりuser1.destroyとかでは効いてもuser1.deleteでは効かない。RailsはDB自体には制約ができない。それに対応するgem(foreigner)を入れる必要がある。Gemの導入Gemfileにforeignerを追加。&apos;foreigner&apos;実際に例で作成してみる今回は次のようなテーブルの場合を考える。usersテーブルにユーザー名、filesテーブルにファイル名。playsテーブルが、どのユーザーが何のファイルを再生したかをカウントする、というもの。playのロー(行データ)はusersテーブルとfilesテーブルに依存している。親のロー(行データ)が更新したら子も更新し、削除されたら子も削除する。モデルの作成は以下のコマンド。user:references注意点は、一度テーブルを作成してからでないと反映できない。別にmigrationファイルを作成する。AddForeignKeyToPlaysAddForeignKeyToPlaysの部分は、AddForeignKeyToテーブル名複数形になる。実際に作成されたmigrationファイルに外部キー制約を記入していく。'付与するSQL制約'のように書く。'付与するSQL制約')のように書く。endend3.の場合は2の括弧を外しただけ。付与するSQL制約は、SQLによって効果が違う。postgresqlの場合だと、以下の表通り。