常連

注目の的

回答者

拍手喝采

自己紹介

###Activerecordの不自然な動作

Activerecordでちょっと不自然な動作を見つけたのですが、ググっても
あまり問題になっていないので皆さんどう思っているのか、どうしているのか聞いてみたくなりました。

例えば以下のようなモデルを作成します

```
class App < ActiveRecord::Base
  attr_accessor :hoge
end
```

前提としてhogeはデータベースに持っていないカラムで、
mogeはデータベースに持っているカラムです。
以下のようなコードでは、mogeが1で取得されますが

```
App.select("1 AS moge").where(:id => 1).first.moge
```


以下の場合はhogeがnilになりました。

```
App.select("1 AS hoge").where(:app_id => 1).first.hoge
```


どうやらデータベースのカラムで持っていなくて、attr_accessorにある場合は
クエリの結果で上書きするのではなく、このインスタンスのhogeにアクセスしているらしく
nilになってしまいました。

この場合、hogeを保存するには以下のようにしないといけないのでしょうか？

```
row = App.select("1 AS hoge").where(:app_id => 1).first
row = App.new(row.attributes.compact)
```

普通に考えてクエリの結果の方を優先して欲しいのですが、そのような動作になってないようです。。

ちなみにバージョンはRails 4.1.4、ruby 2.1.2p95です。

###補足
```
App.select("1 AS hoge").where(:app_id => 1).first[:hoge]
```
で取得しろってことですかねえ。。

カラムhogehogeがある場合
```
App.select("1234 AS hogehoge").where(:app_id => 1).first[:hogehoge]
```
でも

```
App.select("1234 AS hogehoge").where(:app_id => 1).first.hogehoge
```
でも1234になるのに。。

attr_accessorとActiverecordのselect

お世話になっております。

企業から、あるウェブアプリケーションの開発を依頼され、その企業が指定するサーバー（共有レンタルサーバー）に設置し納品となりました。

しかしあるトラブルで相手方が支払いを拒絶し、弁護士に相談のもと、法的手段に流れる運びとなりました。

そこで裁判所に納品したことを証明する必要が出てきたのですが、システムを納品したことを証明するものって、どのようなことがありますでしょうか？

単純にそのシステムが稼動するURLにアクセスすれば、証明は出来ますが、相手方企業がファイルを削除したら確認する術がなくなってしまうかと思います。

他にいい方法はありますでしょうか？

プログラムとは関係ない質問ですが、皆さんのお知恵を頂戴したく、質問させて下さい。

お忙しいところ恐縮ですが、アドバイスのほど宜しくお願い致します。

納品したことを証明するには

rubyのgem、mechanizeでスクレイピングをする際に正規表現のパターンマッチングでデータの抽出を行っているのですが、マッチングが成功してターミナル上に抽出したデータのオブジェクトがMachDataで返ってくるものとNillClassで返ってくるものとがあります。なぜマッチング成功してるのにもかかわらずNillClassで返ってくるのか、原因を教えて下さい????

rubyで正規表現のパターンマッチングをした際、オブジェクトがMatchDataではなくNillClassが返ってくる、、、

株価データをmysqlにinsertするシステムを組んでおります。
全銘柄の株価を1分おきに取得します。
銘柄数は3600、株式市場の時間は1日300分
3600×300=1,080,000レコードとなります。

カラムは以下の通りです。
id int(10) AUTO_INCREMENT
code smalint(5)//銘柄コード
price double//株価
dekidaka int(10)//出来高
created_at date//取得時刻

selectする際の速度を最重視するため、
ストレージエンジンはMyISAMを採用し、ORMは使用しない予定です。
普段テーブル設計をする際はupdated_atカラムを含ませているのですが、
レコード数が膨大になって容量を食う上、updateも行わないため除いています。
・insertは遅くても問題ない
・updateは基本的に行わない(過去の株価は不変)

selectの際、codeもしくはcreated_atを元にpriceを取得したいのですが、
インデックスを付けるのはcodeとcreated_atだけではなく、priceにもつけた方が良いのでしょうか？
○円以上○円未満というbetweenによってpriceを取得します。

その他ご教示頂きたいのは以下の通りです。

・レコードが数億に対し、codeの種類が3600というのはカーディナリティが低いといえるのか
・パーティショニングした方がよいのかテーブルを年毎に分けた方が良いのか
・パーティションはレコード数がどのくらい増えるごとに作成する必要があるのか
・インデックスは部分インデックスにした方がよいのか

宜しくお願いいたします。

※追記
回答者の方からidカラムは不要ではないかとの回答を頂きました。
容量削減のためidカラムを削除する方向へもっていきたいのですが、一意の値のカラムを無くした場合デメリットがありましたらご教示頂けますと幸いです。

1日に100万レコード増える場合のテーブル設計

## 背景

下記の様に各ユーザの購入履歴を記録するテーブルがあります。
この場合に、特定のユーザ達の購入履歴一覧を取得するという事がしたくなりましたが、
その場合のSQLの投げ方に疑問を感じたため質問させていただきました。

## 具体的なテーブル

今回は、このような、ユーザ毎の購入履歴が保存されるようなテーブルを想定しています。

```sql
| purchase | CREATE TABLE `purchase` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` varchar(64) NOT NULL,
  `goods_id` int(10) unsigned NOT NULL,
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `created_at` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
```

## 質問


このテーブルから、冒頭に述べたような `特定のユーザ達の購入履歴を取得する` 場合、
次のようなA(where句にいっきに指定)と、B(SQLを分けて複数回リクエスト)の2種類を思いつきました。

この場合、どちらの方がDBにかかる負荷を抑えられるのでしょうか。
(そもそも、SQLの長さに上限があり、Aの場合でユーザが大量にいるとSQLが発行されなくなるという話を聞いた事がある気も・・)


A. `SELECT user_id, goods_id from purchase where user_id in ('takuya', 'masahiro', 'tuyoshi', 'shingo', .....)`

B. 下記SQLをユーザ数分叩く

`SELECT user_id, goods_id from purchase where user_id = 'takuya'`
`SELECT user_id, goods_id from purchase where user_id = 'masahiro'`
`SELECT user_id, goods_id from purchase where user_id = 'tuyoshi'`
...