
アンチパターンに名前を付けることで、コンテキストを共有できて議論がしやすくなる。2月14日、15日に都内で開催されたイベント「Developers Summit 2013」、通称デブサミにおいて、書籍「SQLアンチパターン」の監訳をした和田卓人氏は本書の意義をこう強調しました。 「SQLアンチパターン」は、データベースにおける設計からアプリケーションに関わるレイヤまで、開発者が陥りやすいミスや誤解に名前を付けたうえで原因と解決策を詳しく解説しています。 和田氏が指摘するように、これまでデータベースに関するデータ設計などのミスを指摘したり議論するには、その背景を共有するための面倒な説明が必要でした。SQLアンチパターンの登場は、そうした背景を暗黙のうちに共有する手段を与えてくれることになります。本書はデータベース分野の古典になる資格を十分に備えているのではないでしょうか。 書籍の監訳者自身が
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
このようなクエリには、2つの前提条件が必要 値が同じ列に格納されていること 例: Bugs.date_reported GROUP BY で正確に日付をグループ化するために、値が比較できること Bugs.date_reported のフォーマットが揃っている必要がある EAV (エンティティ・アトリビュート・バリュー) と呼ばれるアンチパターンを用いていると、上記の前提条件が成立しない問題に遭遇する 日付が行によって違う列に格納されている 例: date_reported, report_date 日付のフォーマットが異なり、簡単には比較できない 5.1 目的: 可変属性をサポートする バグデータベースの例 Issue (問題) を基底型として、Bug と FeatureRequest (機能要望) のオブジェクトを管理する Issue 基底型 - 共通の属性 Date_reported:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く