2015/08/22 YAPC::Asia Tokyo 2015 Lightning Talk 2016/01/13 update about default_password_lifetime will be 0Read less
2015/08/22 YAPC::Asia Tokyo 2015 Lightning Talk 2016/01/13 update about default_password_lifetime will be 0Read less
Scala関西 Summit 2015での発表で触れていたN+1クエリ問題をなんとかするためのライブラリを公開した. 発表は以下のもので, ここでは「関係モナド」という名前で紹介していたけれど, これは口頭でも説明したように便宜上てきとーにつけた名前であって, とくにそういう名前のよく知られたモナドがあるというわけでもなければ, そもそもモナドであるかどうかはあまり本質的ではない. この発表のあとに, Rails (Active Record)でのbulletのようにN+1問題の検出をScalaでやる方法はないだろうか, と言っている人がいたので, そういうものを探していて辿りつけるとよかろうということで, bullet-scalaという名前にした. もちろんN+1問題の検出のためのライブラリというわけではないし, 動的に検出するのではなく原理的に問題が発生しないようにするものなので, 思
最初に調べてから一年経ったので、また GitHub スター数の推移を見てみました*1。というか、こういうの自動化するサービスがあるといい気がしてきたけど。。 DB ライブラリ 順位 名前 2013/06 2013/07 2013/08 2013/09 2013/10 2014/06 総増減 1 Slick 613 638 658 692 717 922 +309 2 postgresql-async 159 187 213 227 240 421 +262 3 Squeryl 322 329 334 338 340 365 +43 4 ScalikeJDBC 112 135 141 150 180 274 +162 5 Querulous 154 157 158 162 164 170 +16 6 scala-activerecord 92 101 104 113 130 168 +76
前回、MongoDBでSNSつくるぞという記事を書いてから随分時間がたってしまいました。単に私がだらけていたということもあるのですが、一番ひっかかって時間を取られていたのが、MongoDBにおけるスキーマ設計の考え方です。 いまだに試行錯誤中ではありますが、現時点において私がこうあるべきと理解しているところをアウトプットしてみたいと思います。 1.One to Many のケース たとえば注文と注文明細のケースを考えてみます。RDBで1対多のリレーションを設計する場合、 というように、注文明細を別テーブルにするのが普通かと思います。しかし、ドキュメント指向のMongoDBにおいては、RDBと違ってオブジェクト内に柔軟なデータ構造を実現できるため、 というように一つのCollection内にデータを埋め込んでしまうのが、パフォーマンスの点からも良しとされています。 ただし、以下の2点について
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く