コンテンツにスキップ
メインメニュー
メインメニュー
サイドバーに移動
非表示
案内
メインページ
最近の更新
未作成ページ
おまかせ表示
ヘルプ
MonoBook
検索
検索
ログイン
個人用ツール
ログイン
ログアウトした編集者のページ
もっと詳しく
投稿記録
トーク
「
データベースの非正規化
」を編集中 (節単位)
ページ
議論
日本語
閲覧
編集
ソースを編集
履歴表示
ツール
ツール
サイドバーに移動
非表示
操作
閲覧
編集
ソースを編集
履歴表示
全般
リンク元
関連ページの更新状況
特別ページ
ページ情報
警告:
ログインしていません。編集を行うと、あなたの IP アドレスが公開されます。
ログイン
または
アカウントを作成
すれば、あなたの編集はその利用者名とともに表示されるほか、その他の利点もあります。
スパム攻撃防止用のチェックです。 けっして、ここには、値の入力は
しない
でください!
=== 非正規化 === その逆に1つのテーブルに重複クソ食らえで全てを詰め込む手法を「データベースの非正規化」と呼ぶ。 {| class="wikitable" |+ ! メーカー !! 住所 !! 商品名 |- | A社 || 北海道 || メロン |- | A社 || 北海道 || ハスカップ |- | B社 || 青森県 || りんご |} こちらは主に膨大な量のレコードを扱う[[ITドカタ]]の現場で使われる教科書クソ食らえな必殺技である。 数億レコードを突破するようなテーブルがいくつも存在する現実的な環境下ではテーブルのJOINなどしたらシステムは窒息死するため、このようなデータベースの設計となる事が多い。 ただし非正規化は諸刃の剣であるということを忘れてはならない。途中での方針変換による採用は非常に危険である。 # 正規化した状態で設計・開発する # サービス開始直後に過負荷でシステムダウン # 非正規を試みる # [[プログラム]]側の非正規化対応という魔改造で[[デスマーチ]]に陥る このような炎上するパターンの根底にあるのは「途中での仕様変更」であり、 見積もり段階でしっかりと想定データ量を算出して、必要に応じて最初から非正規化前提で設計および開発しているプロジェクトは成功することが多い。
編集内容の要約:
MonoBookへの投稿はすべて、他の投稿者によって編集、変更、除去される場合があります。 自分が書いたものが他の人に容赦なく編集されるのを望まない場合は、ここに投稿しないでください。
また、投稿するのは、自分で書いたものか、パブリック ドメインまたはそれに類するフリーな資料からの複製であることを約束してください(詳細は
MonoBook:著作権
を参照)。
著作権保護されている作品は、許諾なしに投稿しないでください!
このページを編集するには、下記の確認用の質問に回答してください (
詳細
):
1たす1は?(全角で入力してください)
キャンセル
編集の仕方
(新しいウィンドウで開きます)
このページは 1 個の隠しカテゴリに属しています:
カテゴリ:スタブ
本文の横幅制限を有効化/無効化