常連

注目の的

自己紹介

forループの中でmysqlクエリを同期的に実行したいのですが、いい方法が思いつきません。
```javascript
//既に上流のclient.queryでrecordSetは取得済み
for( var i=0 ; i < recordSet.length ; i++ ) {
  client.query(
    "SELECT * FROM tablename WHERE foo=?",[recordSet[i].nanika],function(e,r,f){
      console.log(i+"/"+r[0].length );
  });
}
```

（サンプルなのでクエリが非同期じゃなくてもいいじゃないな感じですが、本来は同期処理が必要なクエリです。）

asyncを使って非同期処理を同期的に処理をしたことは有りますが、それではうまくいきませんでした。
なにかヒントで構いませんので、教えていただけますとありがたいです。

forループの中でmysqlクエリを同期的に実行したい

javascriptのbindメソッドは、第一引数にレシーバオブジェクトのthis参照を指定でき、第二引数以降にそのレーシバオブジェクトに渡す引数を指定できるものと認識しております。
下記のソースは、[モジラデペロッパネトワークというサイト](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Function/bind)でbindメソッドを解説し、且つbindの使いどころを指南されているときに出くわしたものです。

list関数に引数を与えると配列として返ってきて、それをlist1変数に代入しています。次に、this参照部分は、必要ないみたいなのでundefined、
list関数に渡したい37を配列の値として持つ返り値をleadingThirtysevenList変数に代入しています。そこに、さらに1と2と3を配列として扱う
list関数に渡し37、1、2、3という四つの値を持つ配列をlist3変数に代入していると読みました。

ここで二つ疑問が沸いたのですが、list関数内にあるsliceメソッドのあとにチェーンされているcallはいったい何の意味があるのでしょうか。
またlist3変数に代入するとき、list.bindを格納しているleadingThirtysevenListに1、2、3という三つの値を引数として受け取っていますが、
第一引数は、undefinedではないのでしょうか。leadingThirtysevenListは、list.bindを格納しているので第一引数は、this参照を指定できるのでは、と思ったのです。
```javascript
function list() {
  return Array.prototype.slice.call(arguments);
}

var list1 = list(1, 2, 3); // [1, 2, 3]

// 先頭の引数がプリセットされた関数をつくる
var leadingThirtysevenList = list.bind(undefined, 37);

var list2 = leadingThirtysevenList(); // [37]
var list3 = leadingThirtysevenList(1, 2, 3); // [37, 1, 2, 3]


```

何故callメソッドがあってundefinedではないのか

例えば一匹ずつポケモンの種類を図鑑に登録するようなデータ構造を作るときにデータベースを使いますか。
データは２００いくか、いかないかくらいになると思います。また，その時,ポケモンの技のテーブルなどを作りますか？

ユーザー一人一人が捕まえたポケモンのデータをデータベースに登録するのであれば分かるのですが，固定数でスケールしないデータをデータベースに格納する実装ってどうなんだろうって思ったのですが,設定ファイルや継承クラスにデータ構造を記述したほうが、保守しやすい気がします。そういう実装のプログラムを見たので普通にやられてることなのかなと疑問に思ったので質問しました。

かと言ってその後，ポケモンが随時増えていくとなると,参照構造の変更(データの順序が変わるなど)に対してシステムがロバストじゃないという点を除いて，数が1000とか2000とか増えるのであればデータベースを利用したら悪いという理由も特段ないような気もするので，速度もkey-valueストアならそこまで問題にならない(さすがに文字列参照より速くはないと思いますが)気もします。ただオブジェクト指向に慣れている身としては,ちょっと違和感があります。
ちなみに初期値のステータスしか変わらないくらいならハッシュやyamlで{"poke1":{attack:10,deffence:20...}"poke2"...}などで設定ファイル作れば十分な気もします。

皆さんはこういうときどういう実装しますか？

データベースを使うか設定ファイル(ロジックやクラス)で済ませるかの判断基準について

株価データを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万レコード増える場合のテーブル設計

エンジニアならこれは読んでおけ みたいな本を教えてください。
ほかにも読んですごく良かった本などでも知りたいです。

アルゴリズムの本や正規表現、TCP/IPなどなど
お願いします

読んでおいたほうがいい本

どのプログラミング言語に限ったことではないのですが例外処理の考え方がいまいちわかりません。

今回はSwift 2を使っています。

do-catch文で例外が起きそうなところをdoブロックで囲むのですが、その例外が起きそうなところすらわからない人はどうすれば良いのでしょうか？
自分でも「ファイルアクセスをしたがファイルがなかった」、「外部APIを叩く際に、APIを提供するサーバがダウンしていた」、「ネットワークの状態が悪く通信できなかった」、「データベースアクセスの際にHDDが破損していて保存できなかった」ぐらいのことはわかるですが、おそらく自分よりできるエンジニアの人はこれ以上の例外処理のケースの引き出しを持っていると思います。

となると、「この処理をした場合、どんな例外が起きるか？」を考えることは大切だとは思うのですが、一般的にはある程度は例外の主なケースを頭に入れておきその処理をする際にdo-catch文を使うという認識であってますでしょうか？

またSwift 2ではenumを使い、ErrorTypeプロトコルに準拠させたエラーの種類の列挙型を作れるのですが、このようにできるということは前もってプログラミングの段階で例外の種類はわかっているということなのでしょうか?
その場合、例外の種類はどの程度で分類するのでしょうか?
例外でもハード系、アプリケーション系、ネットワーク系、その他の4種類に自分は分けられると思っていてとなると
```swift
enum ExceptionError: ErrorType {
	case Hardware
	case Applicatioin
	case Network
	case Other
}
```
になるのでしょうか？

宜しくお願い致します。
特に最初のどこで例外が起きるかの考え方がわからないです。