「達人が語る こんなデータベース設計はヤダ！」へ参加してきました - 虎塚
あの『達人に学ぶDB設計 徹底指南書』を書かれたミックさんが講演されると聞いて、Club DB2さんの勉強会に初めてお邪魔してきました。 「第146回 達人が語る こんなデータベース設計はヤダ！」 https://www.ibm.com/developerworks/wikis/display/clubdb2/146 非常に面白く、勉強になりました。せっかくなので、備忘メモをupしておきます。 （内容に誤りがあったり、もし掲載自体に問題があったりしましたら、修正・削除しますのでお知らせください。＞関係各位） 本編 （追記）発表資料にリンクしました。 http://d.hatena.ne.jp/mickmack/20120714/1342246442 ミックさんが「これだけは覚えて帰ってください」とおっしゃった3つのポイントを引用します。 トレードオフ うまい話には裏がある。 物理 vs 論
REST-ful URI design | 2PartsMagic Blog
This post is about URI naming. Designing URI names. Some tips and rules and conventions that you can follow when figuring out your application's URIs. TheThis post is about URI naming. Designing URI names. Some tips and rules and conventions that you can follow when figuring out your application’s URIs. The focus is on URIs for ‘REST-ful’ applications. But many of the tips apply to any kind
MongoDBにおける関連（Relation）のスキーマ設計 - masa_wの日記
前回、MongoDBでSNSつくるぞという記事を書いてから随分時間がたってしまいました。単に私がだらけていたということもあるのですが、一番ひっかかって時間を取られていたのが、MongoDBにおけるスキーマ設計の考え方です。 いまだに試行錯誤中ではありますが、現時点において私がこうあるべきと理解しているところをアウトプットしてみたいと思います。 １．One to Many のケース たとえば注文と注文明細のケースを考えてみます。RDBで1対多のリレーションを設計する場合、 というように、注文明細を別テーブルにするのが普通かと思います。しかし、ドキュメント指向のMongoDBにおいては、RDBと違ってオブジェクト内に柔軟なデータ構造を実現できるため、 というように一つのCollection内にデータを埋め込んでしまうのが、パフォーマンスの点からも良しとされています。 ただし、以下の2点について
スキーマデザイン - Docs-Japanese - 10gen Confluence
導入 Mongoでは、リレーショナルデータベースのデザインでするような"正規化"はそれほど必要ありません。サーバサイドでの"join"がないからです。一般的には、1つの最上位のオブジェクトレベルに対して、1つのデータベースコレクションを作ることになるでしょう。 すべての"class"について、コレクションを作ることはあまりしません。代わりにembedオブジェクトを使います。例えば、下記の図では、studentsとcoursesの2つのコレクションがあります。studentドキュメントは、courseコレクションを参照する"address"ドキュメントをembedします。 scoreを他のテーブルに入れ、外部キーとしてstudentテーブルにリレーションを持つことになるであろうリレーショナルなスキーマと対比してみてください。 Embed (組み込み) vs. Reference (参照) M
ドメイン駆動設計は設計のアジャイル化～オブジェクト指向設計の先祖返り - プログラマの思索
エリック・エヴァンスのドメイン駆動設計の本を一通り読んでみて、何かすっきりしない感想を持っていた。 @sakaba37さんや@jp_watanabeさんと議論して、すっきりしない原因がようやく分かったのでメモ。 ラフなメモ書き。 【元ネタ】 ドメイン駆動設計: プログラマの思索 ドメイン駆動設計よりもパターン本が好き: プログラマの思索 ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索 DOAとOOAの違い: プログラマの思索 Agile開発に足りないもの～モデリング技術: プログラマの思索 ドメイン駆動設計の本の違和感は二つある。 一つは、分析と設計を区別せず、設計中心の技法ばかり説明していること。 もう一つは、過去のオブジェクト指向設計との違いがはっきり理解できていなかったこと。 前者は、「ドメイン駆動設計」というタイトル通り「
Webアプリのアーキテクチャの歴史と進化 | ありえるえりあ
Webアプリのアーキテクチャの歴史と進化 アリエルネットワークCTO 井上誠一郎 自己紹介+宣伝 書籍 「P2P教科書」 「パーフェクトJava」 「サーバサイドJavaScript入門」 「パーフェクトJavaScript」 今回の講義 - Webアプリのアーキテクチャの俯瞰 - 基軸がないと散漫になるのでPoEAAを開始点 - 専門用語は[用語]ページで整理 参考図書 - PoEAA マーチン・ファウラー http://martinfowler.com/eaaCatalog/index.html - J2EE ロッド・ジョンソン 変わらない目的 - 理解しやすい設計/コード - 変更に強い設計/コード パラダイムシフト(1) - 名著や偉い人の言葉でも、その時代なりの制約の下にある - 制約が変われば常識も変わる パラダイムシフト(2) - Xは正しい... - オブジェクト指向は正し
ドラゴンボールで学ぶオブジェクト指向 改 - 達人プログラマーを目指して
ドラゴンボールといえば、大変に人気の高い国民的、いや世界的な漫画、アニメですが、昨日匿名ダイアリーでドラゴンボールをネタにしたオブジェクト指向の解説がホッテントリに入っていました。 ドラゴンボールで学ぶオブジェクト指向 多くの人に親しみやすい題材でオブジェクト指向の考え方を解説するというのは非常に興味深い試みなのですが、オブジェクト指向の説明としては不適切なところがあり、ちょっと残念な内容になっています。私自身ドラゴンボールの専門家（ドメインエキスパート）ではないため、不正確なところがあるかもしれませんが、ストーリーを思い出しながら、私なりにドラゴンボールをネタとしたオブジェクト指向の解説にリトライしてみたいと思います。 なお、オブジェクト指向でもプログラミング言語によって表現できる内容が異なるため、当然設計技法は違ってきます。ここではJava、C++、C#、Visual Basicといっ
NoSQLデータモデリング技法
NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文：NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Basic Design Note