複数の列を持つ単一の固定テーブルと柔軟な抽象テーブル

特定の問題は、前に明確にして解決する必要があります合理的な議論に入ることができます。

前提条件の解決

ラベル
精度が要求される職業では、混乱を避け、長い説明や修飾子を使用せずに通信できるように、正確なラベルを使用することが重要です。

FixedTablesとして投稿したものは、正規化されていません 。十分に公平なことですが、これは第3正規形での試みかもしれませんが、実際には非正規化（「非正規化」ではない）のフラットファイルです。AbstractTablesとして投稿したのは、正確にはEntity-Attribute-Value<です。 / strong> 、これはほぼ6番目の正規形ですが、完全ではないため、3NFよりも正規化されています。もちろん、正しく行われていると仮定します。

非正規化フラットファイルは「非正規化」されていません。重複（繰り返しグループや重複列を削除したり、依存関係を解決したりするために何も行われていません）とNullがぎっしり詰まっており、多くの点でパフォーマンスを低下させ、同時実行を防ぎます。

非正規化するには、最初に正規化してから、何らかの理由で正規化を少し後退させる必要があります。そもそも正規化されていないため、非正規化することはできません。単純に正規化されていません。

「パフォーマンスのために」非正規化されているとは言えません。パフォーマンスを独占しているため、パフォーマンスとは正反対です。まあ、彼らは形式化されたデザインの欠如の正当化を必要としています]そして「パフォーマンスのために」それはそれです。最小限の正式な精査でさえ、不実表示を明らかにしました（ただし、提供できる人はごくわずかであるため、部外者に対処してもらうまで、それは隠されたままです。これは、大規模なパフォーマンスの問題です）。

正規化された構造は、正規化されていない構造よりもはるかに優れたパフォーマンスを発揮します。正規化された構造（EAV / 6NF）は、正規化されていない構造（3NF / 5NF）よりもパフォーマンスが優れています。

私はOMGポニーの推力に同意しますが、そのラベルと定義には同意しません

「必要がない限り「非正規化」しないでください」と言うのではなく、「 、私は言っています、「忠実に正常化、期間」 および'パフォーマンスの問題がある場合は、正しく正規化されていません' 。

ウィキペディア
正規形と正規化のエントリは、誤った定義を提供します。それらは正規形を混乱させます。彼らは正規化のプロセスに関して欠けています。そしてそれらはずっと前に暴かれたばかげたまたは疑わしいNFに等しい重みを与えます。その結果、ウィキペディアはすでに混乱していてほとんど理解されていない主題に追加します。だからあなたの時間を無駄にしないでください。

しかし、進歩するために、その参照が妨げになることなく、これを言わせてください。

3NFの定義は安定しており、変更されていません。

3NFと5NFの間にはNFの混乱がたくさんあります。真実は、これが過去15年間で進歩した分野であるということです。そして、多くの組織、学者、および製品に制限のあるベンダーが、製品を検証するための新しい「通常のフォーム」を作成するために飛びつきました。すべてが商業的利益に貢献し、学術的に不健全です。元の改ざんされていない状態の3NFは、特定の属性を意図して保証しました。

合計は、5NFが今日であり、3NFが15年前に意図されていたものであり、商用バンターとその間の12個ほどの「特別な」（商用および疑似アカデミック）NFをスキップできます。そのうちのウィキペディアで特定されており、紛らわしい用語でさえも特定されています。

5番目の通常のフォーム
投稿でEAVを理解して実装できたので、次のことを問題なく理解できます。もちろん、真のリレーショナルモデルは前提条件であり、強力なキーなどです。4番目をスキップしているため、5番目の通常の形式は次のとおりです。

第3正規形

簡単に言うと、すべてのテーブルのすべての非キー列は、テーブルの主キーと1：1の関係にあります。

他の非キー列はありません

ゼロデータ重複（正規化が熱心に進められた場合の結果。インテリジェンスや経験だけでは達成されない、または正式なプロセスなしで目標として取り組むことによって達成されない）

更新の異常なし（列をどこかで更新する場合、別の場所にある同じ列を更新する必要はありません。列は1か所にのみ存在します）。

上記を理解していれば、4NF、BCNF、およびすべてのばかげた「NF」を却下できます。これらは、関係モデル（Codd）とはまったく異なる、学者によって推進されている物理化されたレコードファイリングシステムに必要です。

6番目の通常の形式

目的は欠落データの排除です（属性列）、別名ヌルの除去

これは、ヌル問題（欠落値の処理とも呼ばれます）の真の解決策の1つであり、結果としてヌルのないデータベースが作成されます。（標準とNull置換を使用して、5NFで実行できますが、これは最適ではありません。）欠落している値をどのように解釈して表示するかは別の話です。

技術的には、前提条件として5NFがないため、真の正規形ではありませんが、値があります

EAVと6番目の通常のフォーム
私が書いたデータベースは、1つを除いて、すべて純粋な5NFです。私はいくつかのEAVデータベース（管理、修正、拡張）を使用して作業し、多くの真の6NFデータベースを実装しました。 EAVは6NFの緩い実装であり、正規化とNFを十分に理解していないが、EAVの価値を理解し、その柔軟性を必要としている人々によって行われることがよくあります。あなたは完璧な例です。

違いは次のとおりです。緩いため、実装者には忠実な参照（6NF）がないため、必要なものだけを実装し、すべてをコードで記述します。一貫性のないモデルになってしまいます。

一方、純粋な6NFの実装には純粋な学術的基準点があるため、通常はより厳密で一貫性があります。通常、これは2つの目に見える要素で表示されます：

6NFにはメタデータを含むカタログがあり、すべてがコードではなくメタデータで定義されています。 EAVには1つはなく、すべてがコード内にあります（実装者はオブジェクトと属性を追跡します）。明らかに、カタログは列の追加、ナビゲーションを容易にし、ユーティリティを形成することを可能にします。

6NFを理解すると、ヌル問題の真の解決策が提供されます。 EAV実装者は、6NFコンテキストがないため、コード内の欠落データを処理し、一貫性がないか、さらに悪いことに、データベースでNullを許可します。 6NF実装者は、Nullを許可せず、コード構造を必要とせずに、欠落データを一貫してエレガントに処理します（Null処理の場合、もちろん、欠落データをコーディングする必要があります）。

例えば。カタログを備えた6NFデータベースの場合、すべてのSELECTを実行するために必要なSQLを[再]生成する一連のプロシージャがあり、すべてのユーザーに5NFでビューを提供するため、基になる6NF構造を知っている必要はありません。。それらはカタログから追い出されます。したがって、変更は簡単で自動化されています。カタログがないため、EAVタイプは手動でそれを行います。

ディスカッション

これで、ディスカッションを開始できます。

「もちろん、値が事前定義されている場合は、より抽象的な場合があります（例：スペシャリティが独自のリストを持つことができます）」

もちろん。しかし、あまり「抽象的」にならないでください。一貫性を維持し、他のリストと同じEAV（または6NF）の方法でそのようなリストを実装します。

「抽象的なアプローチを採用すると、非常に柔軟になりますが、多くの結合を使用するとクエリがより複雑になります。しかし、これがパフォーマンスに影響するかどうかはわかりません。これらの「より複雑な」クエリを実行してください。」

結合は、リレーショナルデータベースでは歩行者です。問題はデータベースではありません。問題は、結合、特に複合キーを処理するときにSQLが煩雑になることです。

EAVおよび6NFデータベースには、より多くの結合があります。これは、歩行者と同じように、それ以上でもそれ以下でもありません。各SELECTを手動でコーディングする必要がある場合は、確かに、面倒な作業は非常に面倒になります。

問題全体は、（a）EAVよりも6NFを使用し、（b）カタログを実装することで解決できます。カタログから（c）すべての基本的なSQLを生成できます。クラス全体のエラーも排除します。

ジョインにはどういうわけかコストがかかるというのは一般的な神話です。完全に誤りです。

結合はコンパイル時に実装され、CPUサイクルを「コスト」にする実質的なものは何もありません。

問題はテーブルのサイズです同じテーブル間の結合のコストではなく、結合されます。

それぞれが適切なインデックスを持つ正しいPK⇢FK関係で、それぞれ数百万行の2つのテーブルを結合する
（親[PK]側で一意、子側で一意[PK =parent FK+何か]
瞬時

子インデックスが一意ではないが、少なくとも先頭の列が有効である場合、速度は遅くなります。有用なインデックスがない場合、もちろん非常に遅いです。

参加コストとは関係ありません。

多くの行が返される場合、ボトルネックはネットワークとディスクレイアウトになります。結合処理ではありません。

したがって、必要に応じて「複雑」にすることができ、コストはかかりません。SQLで処理できます。

両方の方法の長所と短所を知りたいと思います。自分で想像することはできますが、これを確認する経験がありません。

5NF（または進行していない人の場合は3NF）は、実装の観点から最も簡単で最良です。使いやすさ（開発者とユーザー）。とメンテナンス。

欠点は、列を追加するたびに、データベース構造（テーブルDDL）を変更する必要があることです。場合によっては問題ありませんが、ほとんどの場合、変更管理が実施されているため、非常に面倒です。

次に、既存のコードを変更する必要があります（新しい列を処理するコードは必須であるため、カウントされません）。適切な標準が実装されている場合、それは最小限に抑えられます。それらがない場合、範囲は予測できません。

EAV（投稿したもの）を使用すると、DDLを変更せずに列を追加できます。それが人々がそれを選ぶ唯一の理由です。（新しい列を処理するコードは、必須であるため、カウントされません）。適切に実装されていれば、既存のコードには影響しません。そうでない場合はそうなります。

ただし、EAV対応の開発者が必要です。

EAVの実装が不適切な場合、それは忌まわしいものであり、5NFが不適切に実行されるよりもひどい混乱ですが、ほとんどのデータベースが存在するUnnormalized（「パフォーマンスのために非正規化」と誤って表現される）よりも悪くはありません。

もちろん、列がはるかに分散しているため、強力なトランザクションコンテキストを保持することは（5NF / 3NFよりも）さらに重要です。

同様に、宣言的参照整合性を維持することが不可欠です。私が見た混乱の大部分は、開発者がDRIを「維持するのが困難」になったために削除したことによるものでした。その結果、ご想像のとおり、1人の母親が生まれました。 3NF/5NFの行と列がいたるところに重複しているデータヒープの例。そして、一貫性のないヌル処理。

サーバーが意図した目的のために合理的に構成されていると仮定すると、パフォーマンスに違いはありません。（わかりました。6NFでのみ可能で、他のNFでは不可能な特定の最適化がありますが、それはこのスレッドの範囲外だと思います。）また、EAVが不適切に行われると、不要なボトルネックが発生する可能性があります。正規化されていません。

もちろん、EAVを使用する場合は、より形式的なものをお勧めします。完全なポンドを購入します。 6NFで行く;カタログを実装します。 SQLを生成するユーティリティ。ビュー;欠測データを一貫して処理します。ヌルを完全に排除します。これにより、開発者の品質に対する脆弱性が軽減されます。彼らはEAV/6NFの難解な問題を忘れ、ビューを使用し、アプリロジックに集中することができます。