タグ

Railsとdbに関するanimistのブックマーク (10)

  • 【Rails】ActiveRecord:単一テーブル継承(sti)とポリモーフィック関連を未だにぱっと思い出せないのでまとめ。 - 訳も知らないで

    ActiveRecordで単一テーブル継承(STI:Single Table Inheritance)とポリモーフィック関連という2つの便利なモデルの持ち方?関係性?があるのですが、恥ずかしながらいつも混同してしまいます… 多分頭の中では両方とも「似たモデルをまとめる」みたいなぼんやりした認識してるので混ざってしまっているようで… すごい今更ですが ちょっと自分なりにまとめてみようと思います。 単一テーブル継承(STI:Single Table Inheritance) 同じような機能(メソッド)を持つActiveRecordモデルクラスが2つ存在するので、 継承を使って実装しようとした場合。 例として 「Information」モデルを継承した「Warning」クラスと「Notice」クラスを作成するとします。 (例としておかしかったらごめんなさい…) 単純に実装すると、各モデルに対しD

    【Rails】ActiveRecord:単一テーブル継承(sti)とポリモーフィック関連を未だにぱっと思い出せないのでまとめ。 - 訳も知らないで
    animist
    animist 2013/06/03
    モデルの継承はうまくつかうとおもしろいことができる
  • migrationで複数カラムのindexを生成する時の注意事項 - マオの徒然日記

    Ruby on Railsではmigrationファイルに add_index テーブル名, :カラム名, :unique => true とすることで簡単にテーブルにユニークなindexを生成することが出来ます。 そして、indexに複数のカラムを設定する際は add_index テーブル名, [:カラム名1, :カラム名2, ・・・], :unique => true のようにすることで実現できます。 なので、意気揚々とindexを作成していたら以下のようなエラー。 Index name 'xxxxxxxxxxxxxxxxxxx' on table 'テーブル名' is too long; the limit is 64 characters 何も考えず複数カラムでindexを生成していたら、その名前が長くなりすぎて、エラーとのこと。 64文字以内にしなさいね、ということらしいです。

    migrationで複数カラムのindexを生成する時の注意事項 - マオの徒然日記
  • Railsのモデルに複合一意制約を定義する方法、そしてうっかりハマる - 杉風呂2.0 - A Lifelog -

    Rails 3.0.4で複合一意制約を定義する方法は二通りあるようです。 1.ActiveRecordでモデルに一意制約を定義する 2.RDBMSで一意索引を作る 通常は両方実装するものと思われます。 次のようなモデルで確認します。 class CreateMultiples < ActiveRecord::Migration def self.up create_table :multiples do |t| t.string :key1 t.string :key2 t.string :key3 t.string :value t.timestamps end end def self.down drop_table :multiples end end まず1.の場合ですが、Stack Overflowにありました。 In Rails 2, I would have written:

    Railsのモデルに複合一意制約を定義する方法、そしてうっかりハマる - 杉風呂2.0 - A Lifelog -
  • Ruby on Railsで複合キーを扱う(1)

    Ruby on Railsでは、データベーステーブルの主キーとしてidというカラムを使うのがデフォルトです。 誤解される方も多いのですが、もちろん主キーの名前は変更できます。たとえば、Userモデルに対応するusersテーブルの主キーがuidである場合、次のように書けばOKです。 class User < ActiveRecord::Base self.primary_key = "uid" end 稿のテーマからは外れますが、テーブルの名前も指定できます。テーブルuser_masterをUserモデルで取り扱いたいなら、次のように書きます。 class User < ActiveRecord::Base self.table_name = "user_master" self.primary_key = "uid" end では、主キーが1個ではなく複数個ある場合はどうなるでしょうか。

    Ruby on Railsで複合キーを扱う(1)
    animist
    animist 2012/11/13
  • yuum3のお仕事日記 - migrationファイルの調整、テーブル作成

    Model で作成された各テーブル用migrationファイルに NOT NULL制約や index を追加します。 制約やindexの付け方にはいろいろな流儀があると思いますが、今回は以下のような考え方で付けます。 NOT NULL制約は外部キーのようにそこがnullになってしまうと明らかにデータ構造がおかしくなってしまうカラム また、テーブルの核になるデータでそのカラムがnullのデータというのはありえないカラム index は外部キー等でjoint等で絶対用いられるカラム どのようなルールにするかは、作成するDBの性格や文化があるので、これが正解だというのはありません。ただし、一つのプロジェクトの中では統一された考え方や一貫性があることは重要だと思います。 例: class CreateRequests < ActiveRecord::Migration def self.up cr

    yuum3のお仕事日記 - migrationファイルの調整、テーブル作成
  • Ruby on Rails : migration 機能リファレンス - WebOS Goodies

    WebOS Goodies へようこそ! WebOS はインターネットの未来形。あらゆる Web サイトが繋がり、共有し、協力して創り上げる、ひとつの巨大な情報システムです。そこでは、あらゆる情報がネットワーク上に蓄積され、我々はいつでも、どこからでも、多彩なデバイスを使ってそれらにアクセスできます。 WebOS Goodies は、さまざまな情報提供やツール開発を通して、そんな世界の実現に少しでも貢献するべく活動していきます。

  • Subqueries in activerecord

    With SQL I can easily do sub-queries like this User.where(:id => Account.where(..).select(:user_id)) This produces: SELECT * FROM users WHERE id IN (SELECT user_id FROM accounts WHERE ..) How can I do this using rails' 3 activerecord/ arel/ meta_where? I do need/ want real subqueries, no ruby workarounds (using several queries).

    Subqueries in activerecord
  • 【初級】新人SEのためのSQLの基礎 第3回(後半) 集約関数,GROUP BY句,HAVING句の注意点

    図6●HAVING句の利用上の注意点<BR>HAVING句はWHERE句で置き換えることができる場合がある。図は,同じ結果を検索するHAVING句を利用したSELECT文((1))と,HAVING句を使わないでWHERE句を利用したSELECT文((2))の例である。同じ結果を検索するが,実行性能は(2)WHERE句を利用したSELECT文の方が高い。WHERE句を使った場合はインデックス検索であるが,HAVING句を使った場合は全件検索になる RDBMSには,数値カラムの合計値計算(SUM)や平均値計算(AVG)を行う集約関数が用意されている。例えば図3[拡大表示]の販売テーブルにおいて「値引き」の合計値を求める場合, SELECT SUM(NEBIKI) FROM HANBAI_TBL ; とすると,NEBIKI(値引き)の合計金額を求めることができる(図3(1))。合計値や平均値のほ

    【初級】新人SEのためのSQLの基礎 第3回(後半) 集約関数,GROUP BY句,HAVING句の注意点
  • ActiveRecordのfindで、:includeと:joinsを使ったときの違いって? - 超初心者のロボット製作日記

    頭の中では:includeと:joinsの違いが分かったつもりになっているが、今まで実際に、内部的な動作を詳しく調べたことはなかった。 というわけで、ちゃんと理解するために実験を行ってみた。 モデルはこうなっている。 class Hoge < ActiveRecord::Base has_many :fugas end ビューはこんな感じ。 %h1 Listing hoges %table %tr %th Name - @hoges.each do |hoge| %tr %td= h hoge.fugas[0].name @hoges = Hoge.all(:joins => :fugas) の場合と、 @hoges = Hoge.all(:include => :fugas) の場合で、どういった挙動の違いが出るのかを、ログで確認してみた。 development.log :includ

    ActiveRecordのfindで、:includeと:joinsを使ったときの違いって? - 超初心者のロボット製作日記
  • ActiveRecordのソースコードを読む - (゚∀゚)o彡 sasata299's blog

    2010年06月25日00:18 Ruby ActiveRecordのソースコードを読む ハマったのがきっかけで ActiveRecord 2.3.5 のソースコードを少し読んだので簡単にまとめてみます。なお、ActiveRecord では 2.2 からコネクションプーリングが導入されています。 コネクションプーリングとは? データベースにアクセスする時、アクセスのたびに接続(コネクション)を確立するのではなく、あらかじめ一定数のコネクションを確立しておき、それを使い回す手法。データベースアクセスの負荷を減らすために用いられる。 それを踏まえつつ、検索をする場合の処理を追っていきます。例えば Hoge.find(:all, ...) とかしたらどうなるんでしょうか。 あ、その前に ActiveRecord 使うときって establish_connection が必ず呼ばれます。Rails

  • 1