現場でDBを利用したシステムに携わった後に読むのが良い。なので初心者よりも中級者向けの本。
現場で可動しているシステムがアンチパターンだからといって設計変更になるケースは多くない。特に規模の大きいシステムであればなおさら。なので、実務で得られた設計や手法の問題点を本書で復習し次に活かすのが最適だと感じた。
交差テーブルの利用を避けたいがためにカンマ区切りの値が入った属性を格納するのは、区切り文字やデータ型による格納上限があったりと拡張性が狭まる。正規化して交差テーブルを作成した方がインデックスも利用できるしメリットが多い。
キーワードなどの親子関係を持つテーブルの構成は入れ子集合や閉包テーブルなど有名な設計方法がある。システムの要件に合わせてメリット・デメリットを考慮して選択するのが良い。他の設計に比べて扱い易い閉包テーブルから検討して見るのも悪くない。
JOIN構文で結合条件で利用するカラム名が同じ場合USINGを使うと簡潔になる。ON構文が省略できるため。
auto incrementを利用しidという疑似キーを利用するのは良くある。主キーと疑似キーが混同して利用され煩雑になる可能性を孕んでいる。一部のフレームワークのように疑似キーを主キーとして利用するルールが統一されているのであれば良い。単にidという名ではなくテーブル名にちなんだカラム名を付けるのが良い。
親テーブルのレコードを削除したけど子テーブルのレコードは存在したままになり、検索結果の集計に不適切になるのは、外部キー制約が適切ではない。参照整合性を保つためにも、適切な外部キー制約を付ける。外部キー制約付与によって大きなオーバーヘッドになることはない。
RDBで名前/キーのペア専用の汎用的なテーブルは適さない。必須属性・外部キー制約が使えず参照整合性を維持できない。名前/キーのペアが増えるに従ってJOINの数が増えてSQLが肥大化する。STIや各テーブルに共通の項目をまとめた基底テーブルを利用するCTI、拡張性が高いが絞り込みやソートが難しくなるJSONの利用などを検討する。または、MongoなどのスキーマレスなDBを検討する。
レコード数が多いテーブルのパフォーマンス向上に水平・垂直パーティションが役立つ。
水平についてはシャーディングが有用。例えば、年毎にシャーディングしてレコードを分かりやすく分散。
垂直の場合はTEXTやBLOBで格納されている列を外に出すことを検討する。ワイルドカード(*)で検索が走るとTEXTやBLOBのカラムが参照され重くなる原因になる。
float型は数値が丸まるので、10億倍すると予期せぬ値が返ってくる場合がある。そのため、固定制度の小数点を定義できるnumeric型を使う。
ENUMやCHECK制約は値の種類が増えたり、削除が発生した際に既存のレコードへの対応だけでなく、スキーマの定義変更も必要になるので使う機会はほとんどない。
RAND関数をソート順をランダムにするのは、テーブルスキャンによるソートになり高コスト。また、ソートにインデックスの恩恵も得られない。RDB側でなくアプリケーション側で対応するのが現実的。
複雑なクエリを作成して1発で結果を取得するのは綺麗だが変更に弱い。細かく分解して結果を結合させた方が保守性は高い。
24章のアクティブレコードの話はフレームワーク利用者は一読しておくと参考になる。
モデルがDB操作を簡便にするアクティブレコードという機能を持っている。
フレームワークを利用しているとモデルは1つのテーブルに対するDB操作を担っているように見える。
しかしこれは適切ではなく、モデルはアクティブレコードの機能を持っていて、必要に応じたテーブルへの操作をするものという捉え方の方が適切。
コントローラー側で、次々とモデルを呼び出す処理がある場合は要注意。疎結合、高凝集性を考慮し、それらをまとめるモデルを作成するのが妥当。
Kindle 端末は必要ありません。無料 Kindle アプリのいずれかをダウンロードすると、スマートフォン、タブレットPCで Kindle 本をお読みいただけます。
-
Apple
-
Android
-
Android
無料アプリを入手するには、Eメールアドレスを入力してください。
Kindle化リクエスト
このタイトルのKindle化をご希望の場合、こちらをクリックしてください。
Kindle をお持ちでない場合、こちらから購入いただけます。 Kindle 無料アプリのダウンロードはこちら。
このタイトルのKindle化をご希望の場合、こちらをクリックしてください。
Kindle をお持ちでない場合、こちらから購入いただけます。 Kindle 無料アプリのダウンロードはこちら。
無料で使えるブックカバー
好きなデザインを選んで取り付けよう！ 詳しくはこちら。
商品の説明
内容紹介
本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。
リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗（アンチパターン）があります。
本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分かれて、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。
複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅します。
データベースに関わるすべてのエンジニア必携の一冊です。
内容（「BOOK」データベースより）
データベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分け、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介。複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅。
著者について
Bill Karwin（ビル・カーウィン）：ソフトウェアエンジニアとして20 年以上の経験があり、アプリケーション、ライブラリ、サーバー（Zend Framework for PHP5、InterBaseリレーショナルデータベース、Enhydra Javaアプリケーションサーバーなど）の開発とサポートに携わってきた。キャリアを通じて、自らの知識を他のプログラマーと共有し、成功と生産性向上を支援してきた。数多くの質問に答えるなかで、最も問題を生じさせやすいSQLの典型的なミスについての独自の見解を得るに至った。
著者略歴 (「BOOK著者紹介情報」より)
カーウィン,ビル
ソフトウェアエンジニアとして20年以上の経験があり、アプリケーション、ライブラリ、サーバー(Zend Framework for PHP5、InterBaseリレーショナルデータベース、Enhydra Javaアプリケーションサーバーなど)の開発とサポートに携わってきた
和田/卓人
タワーズ・クエスト株式会社取締役社長、プログラマ、テスト駆動開発者
和田/省二
タワーズ・クエスト株式会社代表取締役。多種多様な業種・業務形態に対してデータモデリングを行い、数多くのデータドメイン設計およびER図を作成する
児島/修
英日翻訳者。1970年生。ビジネス、IT、健康、スポーツなどの分野で活躍中(本データはこの書籍が刊行された当時に掲載されていたものです)
登録情報
|
