よく一緒に購入されている商品
商品の説明
内容紹介
あなたの現場にも必ずあるDBシステムの“悪い例”が満載!
本書は、企業のDBシステムの設計/構築から運用管理、プロジェクト管理までの各フェーズにおけるトラブル(失敗)事例について、アンチパターン(べからず集)とその回避策/防止策を解説するものです。本書で取り上げるのは、筆者がこれまで数々の現場で実際に見てきたシステム関連のトラブルや事故であり、解決のためのノウハウやテクニックと合わせて習得することで、読者自身の現場業務やスキルアップに必ず役立ちます。本書は、月刊DBマガジンの人気特集「アンチパターンに学ぶDBシステム」3回分を加筆/再編集し、書籍としてまとめたものです。
本書は、企業のDBシステムの設計/構築から運用管理、プロジェクト管理までの各フェーズにおけるトラブル(失敗)事例について、アンチパターン(べからず集)とその回避策/防止策を解説するものです。本書で取り上げるのは、筆者がこれまで数々の現場で実際に見てきたシステム関連のトラブルや事故であり、解決のためのノウハウやテクニックと合わせて習得することで、読者自身の現場業務やスキルアップに必ず役立ちます。本書は、月刊DBマガジンの人気特集「アンチパターンに学ぶDBシステム」3回分を加筆/再編集し、書籍としてまとめたものです。
内容（「BOOK」データベースより）
企業のDBシステムの設計/構築から運用管理、プロジェクト管理までの各フェーズにおけるトラブル(失敗)事例について、アンチパターン(べからず集)とその回避策/防止策として解説。
登録情報
|
この商品を見た後に買っているのは？
カスタマーレビュー
最も参考になったカスタマーレビュー
7 人中、7人の方が、｢このレビューが参考になった｣と投票しています。
形式:単行本（ソフトカバー）
表紙にもある通り、実際にあったダメなDBシステムを反面教師にして回避策を学ぶ本です。
読んでみると「あ〜、あるある！」というアンチパターンも多かったです(「データの保持期間を決めていない」とか「不法占拠」とか)。
内容も明快でとても読みやすいです。私は2日ぐらいでほとんど読み終わりました。
全体を通して感じたのはちゃんと本番環境と将来を見据えて設計、テストしなきゃダメだってことです。
ローカルPCと数件のテストデータで開発しても、ちゃんと動いているように見えるだけで実際には使い物にならないことが多いです。
ちゃんと使えるシステムにしようと思うと色々なことを考慮しなければならないわけですが、この本はそういう「色々な考慮点」をうまくまとめてくれていると思います。
システムを設計したり開発したりするときのチェックリストとしても非常に有用なのではないでしょうか。
読んでみると「あ〜、あるある！」というアンチパターンも多かったです(「データの保持期間を決めていない」とか「不法占拠」とか)。
内容も明快でとても読みやすいです。私は2日ぐらいでほとんど読み終わりました。
全体を通して感じたのはちゃんと本番環境と将来を見据えて設計、テストしなきゃダメだってことです。
ローカルPCと数件のテストデータで開発しても、ちゃんと動いているように見えるだけで実際には使い物にならないことが多いです。
ちゃんと使えるシステムにしようと思うと色々なことを考慮しなければならないわけですが、この本はそういう「色々な考慮点」をうまくまとめてくれていると思います。
システムを設計したり開発したりするときのチェックリストとしても非常に有用なのではないでしょうか。
16 人中、14人の方が、｢このレビューが参考になった｣と投票しています。
形式:単行本（ソフトカバー）
この本、私には合いませんでした。
全体的に議論が浅いです。
たとえば、データ設計のアンチパターンとして「ねずみ算：結合する表が多すぎる」というのがあり、
その「典型的な原因」として以下のものが挙げられています。
・SQLの規約を作っていない。もしくは規約が守られていない
・SQLのレビューをしていない
・性能テストをしていない
・単体テストフェーズで実行計画の確認をしていない
・将来を想定した多量データでテストしていない
「結合する表が多すぎる」に対して、この説明では一般的すぎます。
それに、これらは直接の発生原因ではなく、その問題を回避、発見できなかった理由です。
性能テストの有無などは、その問題が発見できなかった理由にはなりますが、問題を引き起こす原因ではありません。
性能テストの実施、SQLのレビューなどは、原因としてではなく、対処として記する方がすっきりすると思います。
原因については、「なぜ結合する表が多くなってしまうのか」という点について、
要件上避けられないことなのか、設計者のスキルによるところなのか
などの根本的な原因を明らかにし、記述すべきだと思います。
具体例が少ないのも不満です。
SQL に関わる問題であれば、「Cプログラミング診断室」のように
そのコーディングの実例を示して欲しいものです。
結局、「結合する表が多すぎる」というアンチパターンの説明を読んでも、
多いとはどの程度なのか（何を以って、多いとしているのか）、
多くてもそれが適切であるのはどのような場面か、
そういった詳細を判断できるほどには至りません。
それから、そもそも、設計・開発の指針を、アンチパターンの形式で記述することに
どれほど意味があるのでしょうか。
「インデックスを適切に設計すべし」と言えば済むところを、
「データ量の暴力」、「過ぎたるはなお及ばざるがごとし」と
よくわからないパターン名で症状を分類し、
アンチパターンの書式に無理やり押し込む。
それこそ、「問題点を説明するのにアンチパターンの書式に頼りすぎる」
というアンチパターンではないでしょうか。
全体的に議論が浅いです。
たとえば、データ設計のアンチパターンとして「ねずみ算：結合する表が多すぎる」というのがあり、
その「典型的な原因」として以下のものが挙げられています。
・SQLの規約を作っていない。もしくは規約が守られていない
・SQLのレビューをしていない
・性能テストをしていない
・単体テストフェーズで実行計画の確認をしていない
・将来を想定した多量データでテストしていない
「結合する表が多すぎる」に対して、この説明では一般的すぎます。
それに、これらは直接の発生原因ではなく、その問題を回避、発見できなかった理由です。
性能テストの有無などは、その問題が発見できなかった理由にはなりますが、問題を引き起こす原因ではありません。
性能テストの実施、SQLのレビューなどは、原因としてではなく、対処として記する方がすっきりすると思います。
原因については、「なぜ結合する表が多くなってしまうのか」という点について、
要件上避けられないことなのか、設計者のスキルによるところなのか
などの根本的な原因を明らかにし、記述すべきだと思います。
具体例が少ないのも不満です。
SQL に関わる問題であれば、「Cプログラミング診断室」のように
そのコーディングの実例を示して欲しいものです。
結局、「結合する表が多すぎる」というアンチパターンの説明を読んでも、
多いとはどの程度なのか（何を以って、多いとしているのか）、
多くてもそれが適切であるのはどのような場面か、
そういった詳細を判断できるほどには至りません。
それから、そもそも、設計・開発の指針を、アンチパターンの形式で記述することに
どれほど意味があるのでしょうか。
「インデックスを適切に設計すべし」と言えば済むところを、
「データ量の暴力」、「過ぎたるはなお及ばざるがごとし」と
よくわからないパターン名で症状を分類し、
アンチパターンの書式に無理やり押し込む。
それこそ、「問題点を説明するのにアンチパターンの書式に頼りすぎる」
というアンチパターンではないでしょうか。
4 人中、4人の方が、｢このレビューが参考になった｣と投票しています。
形式:単行本（ソフトカバー）
アプリ、インフラ、ＰＭとよくあるパターンがまとめられていると思います。
特に、バインド変数やコネクションの再利用など、システムを作る上では
基本的なことですが、守られていないこともあり参考になると思います。
絵で見てわかるＯＳストレージネットワークに比べると、読みやすい内容
になっていると思います。
インフラにはそこまで強くないけど、アプリケーションはそこそこ組んだ
ことがある人向けではないでしょうか？感覚的には３、４年目の社員か、
オラクルマスターを少し取得して、自信をつけてきた人に読んで欲しい
内容です。
特に、バインド変数やコネクションの再利用など、システムを作る上では
基本的なことですが、守られていないこともあり参考になると思います。
絵で見てわかるＯＳストレージネットワークに比べると、読みやすい内容
になっていると思います。
インフラにはそこまで強くないけど、アプリケーションはそこそこ組んだ
ことがある人向けではないでしょうか？感覚的には３、４年目の社員か、
オラクルマスターを少し取得して、自信をつけてきた人に読んで欲しい
内容です。
リストマニア
|
|
同じキーワードの商品を探す
フィードバック
- カタログ情報、または画像について報告
- 著者からのコメント
- 出版社からのコメント
|
