ユーザとユーザを多対多で関連付けるモデルを共通化する - Hidden in Plain Sight
思いのほか前回のRailsプチ・デザインパターンの紹介に反応があったので、こういう小ネタも出していったほうがいいのかな、ということで第二弾。 ソーシャル系アプリだと、ユーザとユーザを関連付ける多対多のモデルがたくさんでてきます。たとえば、一般的なところではフォローとかブロックとか足あととか。さらにデーティングサイトになると、ウィンクだったり、Secret admirer（こっそりlikeするけど両思いだったらおめでとうって通知がくるってやつ）だったり、いろいろなモデルがこのパターンにあてはまります。 この場合、「AがBをフォローしている」「BがAをフォローしている」「AとBがお互いにフォローしている」という3つの状態があるわけですが、相互フォローの状態は「AがBをフォローし、かつBがAをフォローしている」と読み替えてSQLでも記述可能なので、以下ではシンプルに単方向のグラフで全てを扱うもの
DBI->connectの第4引数の内容は設定ファイルに書かないほうが良い | おそらくはそれさえも平凡な日々
Perlでデータベースに接続する場合は以下の様な感じになります。どんなORMなりラッパーなりもDBIを利用しているモジュールは内部的にはこういうことをしているわけです。 DBI->connect($dsn, $user, $password, { mysql_enable_utf8 => 1, RaiseError => 1, PrintError => 0, ShowErrorStatement => 1, AutoInactiveDestroy => 1, }); 第1〜第3引数は環境によって差異があるので設定ファイルに情報を持たせると思います。ただ、それにつられて第4引数も設定ファイルに書いてしまうのが散見されますが、これは良くない。 第4引数の値はプロジェクトでは固定に決まっているので、設定ファイルによって自由度を持たせる必要性が全く無いというかむしろ悪。この人の環境ではテストに通
レコードがなかったらINSERTして返すみたいなのを確実にやる | おそらくはそれさえも平凡な日々
find_or_create的なやつは大体どんなORMでも レコードを探す 無かったらINSERT みたいに実装することになると思う。ただこれだと、1と2の間でレースコンディションでエラー起きることがある。他のプロセスがINSERTしてしまうとかそういうやつ。 それを防ぎたい場合に、1の時点でFOR UPDATEするのはすごくダメで、空行にFOR UPDATEしたりするとMySQLだと盛大に乙るのは有名な話。 エラーを起こさないで、確実にレコードを取りたい場合にはどうすればよいかというと、以下のようにするのが良いと思っている。UNIQUEキー制約なりがちゃんと付いている前提。サンプルコードはTengの場合。 sub find_or_create_surely { my ($self, $table, $where, $opt) = @_; my $row; my $txn = $self-
Entity–attribute–value model - Wikipedia
The EAV data described above is comparable to the contents of a supermarket sales receipt (which would be reflected in a Sales Line Items table in a database). The receipt lists only details of the items actually purchased, instead of listing every product in the shop that the customer might have purchased but didn't. Like the clinical findings for a given patient, the sales receipt is a compact r
HonestyWorks TechNote » EAVモデル
なんでもCMS では「EAVモデル」というデータ構造を採用しています。 EAVとは Entity, Attribute, Value の略です。 この名称が一般的なのかは知りませんが、Magento というeCommerceシステムで EAVモデルという言葉が使われています。 http://4plus.jp/tech/2011/02/magentoeav.html 従来のRDBMSよるスキーマ構造とは大きく異なり、本来テーブルとして定義すべきものを全て Entity, Attribute, Value の3つのテーブルで管理します。（なんでもCMSではRecordというテーブルも使っています。） これにより管理画面から自由にオブジェクト設定(＝データベースのテーブル設計)ができ、動的に変更が可能な構成を実現しています。メタデータがDBに登録されているので画面の生成なども容易に自動化できるわ
MagentoのEAVモデル | 4plus tech
例えばMagentoの商品で言えば、商品1はspecial_from_date（特別価格開始日）の値があって、商品2では値がないかもしれません。
Entity-Attribute-Valueモデル - ROUTE 3390
ECパッケージ Magento で使われているEAVモデルについて、自分なりに理解できているか確認の意味も込めてまとめます。 誤りなど気づいた方がいらしたら、是非つっこんでください。 まずよくあるユーザーテーブル ▼customer_table id name birthday address 1 sasakure 1984/12/03 tokyo shibuya 2 tarou 2002/01/22 kanagawa kawasaki これをEAVモデルにすると下記のようになります。 まずはEntity ▼entities_table id 1 2 Entityは「実態」とか「実在」という意味です。 この場合「ユーザ」を表します。 最低でもidだけあればEntityとして充分です。 次にAttribute ▼attributes_table id attributes_name 1 na
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
FuelPHP: Add multiple many-to-many relationships