データベースの正規化は停止していますか？[閉まっている]

私は古い学校に育ちました-アプリケーションのビジネスレイヤーの前にデータベーススキーマを設計することを学びました（または他のすべてにOOADを使用しました）。私はスキーマ（IMHO :)の設計にかなり長けており、不必要な冗長性を削除するためだけに正規化しましたが、速度に影響を与える場所ではありません。つまり、結合がパフォーマンスに影響した場合、冗長性はそのまま残されました。しかし、ほとんどそうではありませんでした。

RubyのActiveRecordやActiveJDBCなどのいくつかのORMフレームワークの出現により（覚えていないが他にもいくつかありますが、たくさんあると確信しています） 「メール」-2NFを完全に破壊します。さて、あまり理解していませんが、これらのORM（またはプログラマー）の一部が1-1または1-0 | 1（つまり、1対0または1）を認識しないと、（ほとんど）緊張します。彼らは、nulls 「今日のシステムがそれを処理できる」という大量の情報がある場合でも、すべてを1つの大きなテーブルとして保持する方が良いと述べています。

メモリの制約は正規化と直接的な相関関係があることに同意します（他の利点もあります:)が、今日の安価なメモリとクアッドコアマシンでは、DB正規化の概念はテキストに残されていますか？DBAは3NF（BCNFではない場合）への正規化を実践していますか？それは重要ですか？「ダーティスキーマ」設計は本番システムに適していますか？それがまだ関連している場合、どのように「正規化」のためにケースを作るべきか。

（注：設計の一部/必要性として冗長性を備えたデータウェアハウスのスター/スノーフレークスキーマについてではなく、たとえばStackExchangeのようなバックエンドデータベースを備えた商用システムについてです）

正規化の理由の1つは、
ORMが通常これをサポートしないデータ変更の異常を取り除くことです。

この原則を破るHibernateで設計されたデータベースの多くの例があります。

• 肥大化（数億行にわたって繰り返される文字列）
• ルックアップテーブルなし（上記を参照）
• DRIなし（制約、キー）
• varcharクラスター化インデックス
• 不要なリンクテーブル（たとえば、NULL入力可能なFK列で十分な場合に1..0：1を強制する）

私が見てきた最悪の事態は、1TBのMySQLデータベースであり、これらのために75〜80％が大きすぎる可能性があります。

また、「今日のシステムで処理できる」という記述は、ほとんどのミッキーマウスシステムに当てはまることをお勧めします。スケーリングしても、今日のシステムはそうではありません。

上記の私の例では、キーのリファクタリングや変更、またはデータの修正を行うための牽引力はありませんでした。

「メール」などの主キーを持っている場合でも、すべてのテーブルに代理キーを使用することを好むようです-2NFを完全に破壊します。

代理キーは2NFを壊しません。2NFは、「列が複数値キーの一部のみに依存している場合、その列を別のテーブルに削除します。」と言います。

彼らは、nullがたくさんある場合でも、すべてを1つの大きなテーブルとして持つ方が良いと規定しています

1つのテーブルに複数の列を含めることは、正規化ルールに従っている限り有効です。SQLと正規化の利点を享受したい場合、分析せずにテーブルをマージするのは正しくありません。

メモリの制約が正規化と直接相関していることに同意します。リレーション正規形は数学的概念であり、メモリとは関係ありません。

正規化は、メモリまたはディスクを保存するだけでなく、整合性を追加するためにもあります。結局のところ、それはハードウェアに依存しない数学的概念です。

簡単な例：学校情報を次のように管理するとします：

Rec 1：ノースリッジ高校、カリフォルニア、アメリカ

Rec 2：カナダ、オンタリオ州サウストロントブレイブス高校

システムにオンタリオ州の場所を尋ねると、カナダにあることがわかります。数日後、2行目を削除してシステムに同じ質問をしますが、何も表示されません。この例では、ディスク容量、メモリ、またはCPUの量に関係なく、答えは得られません。

これは、関係を正常化して異常を防ぐ1つの方法です。

編集：以下のコメントに従って、トロントという言葉をオンタリオに変更しました。

より多くのものが変化すればするほど、彼らは同じままです。角を切ったり、ベストプラクティスを知らない、または従おうとしない怠け者の開発者が常にいました。多くの場合、彼らは小さなアプリケーションでそれを回避することができます。

以前は、COBOLに触発されたデータ構造を初期のRDBMS、またはdBaseであったゴッドアワー混乱に詰め込んでいた。今ではORMと「コードファースト」です。結局、これらはすべて、あなたが何をしたいのか、何をする必要があるのか​​を一生懸命に考えずに、作業システムを手に入れるという特効薬を見つけようとする人々の単なる方法です。急いでいることは常に問題であり、常に問題になります。

適切に設計するのに時間をかける良識（および幸運）を持っている人にとって、データモデルは常に最も論理的な出発点です。データベースにあるのは、あなたのビジネスが気にしているもの（有形および無形）に関する情報です。 あなたのビジネスが気にするものは、あなたのビジネスがどのように運営されるかよりもはるかに早く変化します。これが、データベースが一般にコードよりもはるかに安定している理由です。

データベースは、あらゆるシステムの正当な基盤であり、基盤を適切に構築するために時間をかけることは、長期的には必然的に利益をもたらします。つまり、正規化は、OLTPタイプのアプリケーションにとって常に重要かつ有用なステップになるということです。

メモリの制約が正規化と直接相関していることに同意します...

メモリの制約は依然として重要です。量は問題ではなく、速度は問題です。

• CPUは現時点では高速化されていません（1秒あたりのサイクル数ではなく、コア数が増えています）
• 最新のCPUアーキテクチャは、各プロセッサに個別のメモリを提供することで速度制限を克服しようとします（NUMA）にます。
• ダイ上のキャッシュサイズは、メインメモリに匹敵する速度で成長していません。
• メモリのスループットは、ほとんどの人が期待するほど高くありません。QPIは約25GB /秒です。

この根拠の一部は、INTでTINYINTを使用するタイミングで説明されています。役に立つかもしれません。また、SQLCATチームの@ThomasKejser（ブログ）のふざけた態度に従うことをお勧めします。これは、データベースパフォーマンスをプッシュする際に鋭い傾向があるためです。CPUキャッシュとメモリアクセスパターンの効果に関する最近の投稿と、エクストリームDWスケールのリレーショナルモデリングに関するSQLBitsプレゼンテーションは良い例です。

私の意見では、それはまだ正規化と非正規化のバランスについてです。ORMフレームワークは単に物事を成し遂げるためのアプローチにすぎないことに完全に同意しますが、これらのフレームワークが非正規化を引き起こすとは思いません傾向。

時間の効率化やスペースの効率化が必要な議論はまだあります。リレーショナルデータベース理論が生まれたとき、ディスクストレージは高価であり、人々は明らかにこれにそれほどお金をかけたくないので、その時、リレーショナルデータベースは逆境の中でしっかりしている理由です。

今では物事はかなり異なり、ストレージは非常に安価です。したがって、明らかに、昔と比較してより多くの冗長性を許容できます。これは、BIG_TABLEアプローチが登場した理由でもあります。より多くの時間効率を求めるには、スペース効率を犠牲にする必要があります。

しかし、ビッグテーブルアプローチも話の終わりではなく、管理するPBボリュームデータの点で時間とスペースのバランスであり、一部の開発者はスペース効率に戻るバランスを模索し始めました。 BIG-TABLEのような構造の一部のデータを正規化するために行われる作業です。

一言で言えば、正規化のアプローチは間違いなく死んでいませんが、昔と比べて間違いなく見落とされています。

CJ Dateはここであなたの質問に答えます-正規化（予備）ビデオは無料です。

http://shop.oreilly.com/product/0636920025900.do

簡単な答え：正規化は、数学的に正しい方法です。適切に正規化しないと、データモデルが単純に不正になります。