null許容列または個別のテーブルに対してキー/値テーブルを使用することの[デメリットは何ですか？
少し前に作成した支払い管理システムをアップグレードしています。現在、受け入れることができる支払いタイプごとに1つのテーブルがあります。このアップグレードによって軽減されるのは、1つの金額のみを支払うことができるという制限です。私はそれをどのように設計すべきかについての提案を求めてきました、そして私はこれらの基本的な考えを持っています：
- 支払いタイプごとに1つのテーブルがあり、それぞれにいくつかの共通の列があります。 （現在のデザイン）
- すべての支払いを、共通の列（タイプに関係なく支払いIDを統合する）をとる中央テーブルと調整し、その支払いタイプに固有の列を持つ別のテーブルと行IDを識別します。
- すべての支払いタイプに対して1つのテーブルを用意し、特定のタイプに使用されない列をnullにします。
- 中央テーブルのアイデアを使用しますが、特殊な列をキー/値テーブルに格納します。
これに対する私の目標は、ばかばかしいほど遅くならないこと、可能な限り自己文書化すること、そして他の目標を維持しながら柔軟性を最大化することです。
各テーブルの列が重複しているため、1はあまり好きではありません。これは、すべての支払いタイプに機能を提供する基本クラスを継承する支払いタイプクラスを反映しています... ORMは逆ですか？
現在の設計と同じように「タイプセーフ」で自己文書化されているため、私は2に最も傾いています。ただし、1と同様に、新しい支払いタイプを追加するには、新しいテーブルを追加する必要があります。
3は「無駄なスペース」があるため、好きではありません。また、どの列がどの支払いタイプに使用されているかがすぐにはわかりません。ドキュメントはこれの苦痛をいくらか軽減することができますが、私の会社の内部ツールには、技術ドキュメントを保存/検索するための効果的な方法がありません。
私が4に対して与えた議論は、新しい支払い方法を追加するときにデータベースを変更する必要性を軽減するだろうというものでしたが、明確さの欠如のために3よりもさらに悪い問題を抱えています。現在、データベースの変更は問題ではありませんが、将来的に顧客が自分のデータベースを保持できるようにすることを決定した場合、ロジスティックの悪夢になる可能性があります。
ですから、もちろん私には偏見があります。誰かもっと良いアイデアはありますか？どのデザインが最適だと思いますか？どの基準に基づいて決定する必要がありますか？
おそらくあなたは見るべきです この質問
ビルカーウィンから受け入れられた回答は、通常、エンティティ属性値（EVA）として知られているキー/値テーブルに対する特定の議論に入ります。
..多くの人がEAVを好むようですが、私はそうではありません。これは最も柔軟なソリューションのように思われるため、最良のソリューションです。ただし、格言 [〜＃〜] tanstaafl [〜＃〜] を覚えておいてください。 EAVの欠点のいくつかを次に示します。
- 列を必須にする方法はありません（
NOT NULLと同等）。- SQLデータ型を使用してエントリを検証する方法はありません。
- 属性名のスペルが一貫していることを確認する方法はありません。
- 特定の属性の値に外部キーを設定する方法はありません。ルックアップテーブル用。
- 複数の行から属性を取得するには、属性ごとに
JOINを実行する必要があるため、従来の表形式のレイアウトで結果をフェッチすることは複雑でコストがかかります。EAVがもたらす柔軟性の程度は、他の領域で犠牲を払う必要があり、おそらく、従来の方法で元の問題を解決する場合よりもコードが複雑（または悪化）になります。
そして、ほとんどの場合、その程度の柔軟性を持つ必要はありません。製品タイプに関するOPの質問では、製品固有の属性の製品タイプごとにテーブルを作成する方がはるかに簡単であるため、少なくとも同じ製品タイプのエントリに対して一貫した構造を適用できます。
すべての行に個別の属性セットを含めることを許可する必要がある場合にのみ、EAVを使用します。製品タイプのセットが限られている場合、EAVはやり過ぎです。クラステーブル継承が私の最初の選択です。
注
このテーマは議論されており、このスレッドは他のスレッドで参照されているので、私はそれに合理的な扱いをしました。ご容赦ください。私の意図は、あなたができるように理解を提供することです。ラベルだけに基づく単純な決定ではなく、情報に基づいた決定。それが激しいと感じた場合は、暇なときにまとめて読んでください。空腹のときに戻ってきてください。前ではありません。
EAVについて、正確には「悪い」とは何ですか？
1はじめに
3NFが適切に行われた場合と不適切に行われた場合に違いがあるのと同様に、EAVが適切に行われた場合と不適切に行われた場合には違いがあります。私たちの技術的な仕事では、何が機能し、何が機能しないかを正確に把握する必要があります。何がうまく機能し、何がうまく機能しないかについて。包括的な声明は危険であり、人々に誤った情報を提供するため、関係する問題の進展と普遍的な理解を妨げます。
私は、熟練していない労働者による不十分な実施と、基準への準拠のレベルを誤って伝えていることを除いて、何に対しても賛成でも反対でもありません。そして、私が誤解を感じるところでは、ここで、私はそれに対処しようとします。
正規化も誤解されることが多いので、それについて一言。 Wikiやその他の無料のソースは、実際には完全に無意味な「定義」を投稿しています。これは、学術的根拠がなく、標準に準拠していない製品を検証するためにベンダーのバイアスがあります。コッドが彼の12のルールを公開しています。私は最低5NFを実装していますが、これはほとんどの要件に十分すぎるため、それをベースラインとして使用します。簡単に言えば、第3正規形が読者に理解されていると仮定します（少なくともその定義は混乱していません）...
2 5番目の通常の形式
2.1定義
5番目の通常の形式は次のように定義されます。
- すべての列は主キーと1：1の関係にありますが、
- 他の列、テーブル、または他のテーブルにはありません
- 結果は、どこにも重複する列はありません。更新の異常はありません（列が更新されたときに、その重複が正しく更新されるようにするためのトリガーや複雑なコードは必要ありません）。
- （a）影響する行が少なくなり、（b）ロックが減少するため同時実行性が向上するため、パフォーマンスが向上します。
データベースが特定のNFに正規化されているかどうかではないことを区別します。データベースは単に正規化されています。 各テーブルは特定のNFに正規化されています。一部のテーブルは1NFのみを必要とし、他のテーブルは3NFを必要とし、さらに他のテーブルは5NFを必要とします。
2.2パフォーマンス
正規化ではパフォーマンスが得られないと人々が考え、「パフォーマンスのために非正規化」する必要があった時期がありました。神話が暴かれたことを神に感謝し、今日のほとんどのIT専門家は、正規化されたデータベースのパフォーマンスが向上していることを認識しています。データベースベンダーは、正規化されていないファイルシステムではなく、正規化されたデータベースを最適化します。 「非正規化」された真実は、データベースが最初から正規化されておらず（そしてパフォーマンスが悪い）、正規化されておらず、パフォーマンスを向上させるためにさらにスクランブルをかけたということです。非正規化されるためには、最初に忠実に正規化される必要があり、それは決して起こりませんでした。私はそのような「パフォーマンスのために非正規化された」データベースのスコアを書き直し、忠実な正規化だけを提供しました。それらは少なくとも10回、100回も実行されました回 もっと早く。さらに、必要なディスク容量はごくわずかでした。非常に歩行者であるため、書面での運動を保証します。
2.3制限
制限、またはむしろ5NFの全範囲は次のとおりです。
- オプションの値を処理せず、Nullを使用する必要があります（多くの設計者はNullを許可せず、代替を使用しますが、適切かつ一貫して実装されていない場合、これには制限があります）
- 列を追加または変更するには、引き続きDDLを変更する必要があります（実装後、最初に識別されなかった列を追加するための要件がますます増えています。変更管理は面倒です）
- 正規化（読み取り：重複や混乱した関係の排除）により最高レベルのパフォーマンスを提供しますが、ピボット（行のレポートまたは行の要約を列として表現）や「列アクセス」などの複雑なクエリは、データウェアハウスの操作は困難であり、それらの操作だけではうまく機能しません。これは、使用可能なSQLスキルレベルのみによるものであり、エンジンによるものではありません。
3第6正規形
3.1定義
6番目の通常の形式は次のように定義されます。
- 関係（行）は主キーと最大で1つの属性（列）です
これ以上実行できる正規化はありませんがないため、これはIrreducible Normal Form、究極のNFとして知られています。それは90年代半ばに学界で議論されましたが、2003年にのみ正式に宣言されました。関係、関係、「関係」などを混乱させることによって、関係モデルの形式を軽視するのが好きな人のために。正式には、上記の定義は既約関係を識別し、原子関係と呼ばれることもあるため、ベッドに置かれます。
3.2進行
6NFが提供する（5NFが提供しない）増分は次のとおりです。
- オプション値の正式なサポート、したがって、ヌル問題の排除
- 副作用は、DDLを変更せずに列を追加できることです（後で詳しく説明します）
- 楽なピボット
- シンプルで直接的な柱状アクセス
- これにより、（バニラ形式ではなく）この部門でさらに高いレベルのパフォーマンスが可能になります
私（および他の人）は、20年前に拡張5NFテーブルを明示的にピボット用に提供していて、まったく問題がなかったため、（a）単純なSQLを使用でき、（b）非常に高いパフォーマンスを提供できました。業界の巨人が私たちがしていることを正式に定義したことを知って良かったです。一晩で、私の5NFテーブルは私が指を離さずに6NFに名前が変更されました。次に、必要な場合にのみこれを実行しました。繰り返しになりますが、6NFに正規化されたのはデータベースではなく、テーブルでした。
3.3 SQLの制限
これは面倒な言語であり、特に再結合であり、適度に複雑なことを行うと非常に面倒になります。 （これは、ほとんどのコーダーがサブクエリを理解または使用しない別の問題です。）5NFに必要な構造をサポートしますが、それはただのことです。堅牢で安定した実装を行うには、追加のカタログテーブルで部分的に構成される可能性のある追加の標準を実装する必要があります。 SQLの「使用期限」は、90年代初頭までに十分かつ真に経過していました。 6NFテーブルのサポートがまったくなく、必死に交換が必要です。しかし、私たちが持っているのはそれだけなので、Deal With Itだけにする必要があります。
標準と追加のカタログテーブルを実装していた私たちにとって、6NF構造をサポートするために必要な機能を提供するためにカタログを拡張することは深刻な努力ではありませんでした標準へ：どの列がどのテーブルに属し、どのような順序で;必須/オプション;表示形式;など。本質的には、SQLカタログと結合した完全なMetaDataカタログです。
各NFには以前の各NFが含まれているため、6NFには5NFが含まれていることに注意してください。 6NFを提供するために5NFを壊したのではなく、5NFからの進行を提供しました。 SQLが不足している場合は、カタログを提供しました。これが意味するのは、外部キーなどの基本的な制約です。 SQL宣言型参照整合性を介して提供されたバリュードメイン。データ型;小切手;そして、5NFレベルのルールは無傷のままであり、これらの制約は覆されませんでした。標準に準拠した5NFデータベースの高品質と高性能は、6NFを導入しても低下しませんでした。
3.4カタログ
ユーザー（任意のレポートツール）と開発者を、5NFから6NFへのジャンプに対処する必要から保護することが重要です（アプリコーディングオタクになるのは彼らの仕事であり、データベースオタクになるのは私の仕事です）。 5NFでも、それは常に私にとっての設計目標でした。最小限のデータディレクトリを備えた適切に正規化されたデータベースは、実際には非常に使いやすく、それをあきらめる方法はありませんでした。通常のメンテナンスと拡張により、6NF構造は時間の経過とともに変化し、データベースの新しいバージョンが定期的に公開されることに注意してください。間違いなく、6NFテーブルから5NF行を構築するために必要なSQL（5NFではすでに面倒です）はさらに面倒です。ありがたいことに、それは完全に不要です。
完全な6NF-DDL-that-SQL-does-not-provideを識別するカタログがすでにあるので、必要に応じて、カタログを読み取るための小さなユーティリティを作成しました。
- 6NFテーブルDDLを生成します。
- 6NFテーブルの5NFビューを生成します。これにより、ユーザーは幸いにも彼らに気づかず、5NFと同じ機能とパフォーマンスを得ることができました。
- 6NF構造に対して動作するために必要な完全なSQL（テンプレートではなく、個別に用意されています）を生成し、コーダーが使用します。それらは、他の方法で要求される退屈な繰り返しから解放され、アプリのロジックに自由に集中できます。
5NFに存在する複雑さが解消され、5NFで拡張されたピボットの場合と同様に、簡単に記述できるようになったため、ピボット用のユーティリティは作成しませんでした。さらに、ほとんどのレポートツールはピボットを提供するため、クライアントに出荷する前にサーバーで実行する必要がある統計の大量の攪拌を含む関数を提供するだけで済みます。
3.5パフォーマンス
誰もが苦しむ「病気」、耐える十字架を持っています。私はたまたまパフォーマンスに夢中になっています。私の5NFデータベースはうまく機能したので、本番環境に何かを配置する前に、必要以上に多くのベンチマークを実行したことを保証します。 6NFデータベースのパフォーマンスは5NFデータベースとまったく同じで、良くも悪くもありません。これは当然のことです。「複雑な」6NFSQLが実行するのは、5NF SQLが実行しない唯一のことであり、はるかに多くの結合とサブクエリを実行することです。
あなたは神話を調べる必要があります。
- この問題のベンチマークを行った（つまり、クエリの実行プランを調べた）人なら誰でも、Joins Cost Nothing、これはコンパイル時の解決策であり、実行時には効果がないことを知っているでしょう。
- はい、もちろん、結合されたテーブルの数。結合されるテーブルのサイズ。インデックスを使用できるかどうか。結合されているキーの配布。など、すべて何かがかかります。
- ただし、結合自体には費用はかかりません。
- 正規化されていないデータベースの5つの（大きい）テーブルに対するクエリは、正規化されている場合、同じデータベース内の10の（小さい）テーブルに対する同等のクエリよりもはるかに低速です。重要なのは、4つも9つの結合も費用がかからないということです。彼らはパフォーマンスの問題を理解していません。各結合で選択されたセットは、その中に含まれています。
3.6メリット
無制限の柱状アクセス。これが6NFが本当に際立っているところです。直線的な柱状アクセスは非常に高速であったため、特殊なDW構造から速度を取得するためにデータをデータウェアハウスにエクスポートする必要はありませんでした。
いくつかのDWについての私の調査では、完全ではありませんが、6NFが行うのとまったく同じように、行ではなく列ごとにデータを一貫して格納していることが示されています。私は保守的であるため、6NFがDWに取って代わると宣言するつもりはありませんが、私の場合は、DWの必要性がなくなりました。
明らかにはるかに高速に実行された5NFでは利用できなかった6NFで利用可能な機能（例：ピボット）を比較することは公平ではありません。
これは私たちの最初の真の6NFデータベースであり（完全なカタログなどを備えています。必要な場合にのみ拡張された常に5NFであり、後で6NFであることが判明しました）、顧客は非常に満足しています。もちろん、納品後しばらくの間パフォーマンスを監視していたので、次の6NFプロジェクトでさらに高速な柱状アクセス方法を特定しました。それは、私がそれを行うとき、DW市場に少し競争をもたらすかもしれません。お客様の準備ができていないため、壊れていないものは修正しないでください。
3.7正確には、6NFについて、「悪い」とは何ですか？
誰もが同じくらい形式的、構造的、そして基準を順守して仕事に取り組むわけではないことに注意してください。したがって、私たちのプロジェクトから、すべての6NFデータベースが適切に機能し、保守が容易であると結論付けるのはばかげています。 （他の実装を見て）すべての6NFデータベースのパフォーマンスが悪く、保守が難しいと結論付けるのも同様にばかげています。災害。いつものように、技術的な努力によって、結果として得られるパフォーマンスと保守の容易さは、関連するスキルセットに加えて、形式、構造、および標準への準拠に厳密に依存します。
3.8可用性
「公開された参照」など、標準的な商慣行の境界を超えて自分自身を公開したり、要求したりしないでください。顧客はオーストラリアの銀行であり、実装全体は機密情報です。しかし、私は訪問の見通しを自由に取ることができます。また、シドニーのオフィスでドキュメントを表示することもできます（コピーはできません）。方法論（公に利用可能な6NF教育を超えた構造と標準）とユーティリティは、私たち独自の知的財産であり、割り当てに利用できます。この段階では、（a）プロジェクトの成功を合理的に保証する必要があり（評判を傷つけないため）、（b）成功したプロジェクトが1つでは不十分であるため、割り当ての一部としてのみ販売しています。それを「市場に出す準備ができている」として分類するための成熟度。
IP（ドキュメント）を実際に公開することなく、引き続き質問に回答し、6NFカタログに関する役立つ情報、機能するものと機能しないものに関するアドバイスなどを提供できることをうれしく思います。また、適格なベンチマークを実行できることをうれしく思います。
4エンティティ属性値
開示：経験。私はこれらのいくつか、主に病院と医療システムを検査しました。そのうちの2つに修正割り当てを実行しました。海外プロバイダーによる最初の配信は、素晴らしいものではありませんが、十分でしたが、拡張機能が実装されました。地元のプロバイダーによる混乱でした。しかし、人々がこのサイトにre EAVについて投稿した災害はほとんどありませんでした。数か月の集中的な作業により、問題は解決しました。
4.1それは何ですか
私が取り組んできたEAVの実装は、第6正規形のサブセットにすぎないことは明らかでした。 EAVを実装する人は、6NFの機能（たとえば、DDLを変更せずに列を追加する機能）のsomeが必要なためにそうしますが、真の6NFを実装するための学術的知識、または標準とそれを実装および管理するための構造安全に。元のプロバイダーでさえ、6NFについて、またはEAVが6NFのサブセットであることを知りませんでしたが、私が彼らに指摘したとき、彼らはすぐに同意しました。 EAV、そして実際には6NFを効率的かつ効果的に提供するために必要な構造（カタログ、ビュー、自動コード生成）は、EAVコミュニティでは正式に識別されておらず、ほとんどの実装から欠落しているため、EAVをろくでなしの息子として分類します。 6番目の通常の形式。
4.2 EAVについて、正確には「悪い」とは何ですか？
このスレッドや他のスレッドのコメントを見ると、そうです、EAVがうまくいかなかったのは惨事です。さらに重要なのは、（a）5NFで提供されるパフォーマンスが失われるほど悪い（6NFを忘れる）こと、および（b）複雑さからの通常の分離が実装されていないことです（コーダーとユーザーは面倒なナビゲーションを使用するように「強制」されます）。そして、彼らがカタログを実装していなければ、あらゆる種類の予防可能なエラーは防止されなかったでしょう。悪い（EAVまたは他の）実装にはそれが当てはまるかもしれませんが、6NFまたはEAVとは何の関係もありません。私が取り組んだ2つのプロジェクトは、非常に適切なパフォーマンス（確かに、改善される可能性がありますが、パフォーマンスの低下はありませんでしたEAVによる）、および複雑さの分離が良好でした。もちろん、それらは私の5NFデータベースまたは私の真の6NFデータベースの品質やパフォーマンスにはほど遠いものでしたが、EAVコミュニティ内に投稿された問題の理解のレベルを考えると、十分に公平でした。それらは災害ではなく、これらのページでEAVであると主張されている標準以下のナンセンスでした。
5ヌル
ヌル問題と呼ばれるよく知られた文書化された問題があります。それだけでエッセイに値する。この投稿では、次のように言うだけで十分です。
- 問題は、実際にはオプションの値または欠落している値です。ここで考慮すべきことは、NullとNullable列がないようなテーブル設計です。
- 実際には問題ではありません。なぜなら、欠落値を除外するためにNulls/No Nulls/6NFを使用するかどうかに関係なく、そのためにコーディングする必要があります、正確には欠落している値の処理、これは回避できません
- もちろん、帰無仮説を排除する純粋な6NFを除きます。
- 欠落した値を処理するためのコーディングは残ります
- ただし、SQLコードの自動生成では、
- Nullはパフォーマンスにとって悪いニュースであり、私たちの多くは数十年前にNull inデータベースを許可しないことを決定しました（渡されたパラメーターと結果セットのNullは、欠落している値を示すために問題ありません）
- これは、欠落している値を示す一連のヌル置換とブール列を意味します
- ヌルを指定すると、固定されているlen列が変数lenになります。トラバーサルまたはダイブ中に、すべてのインデックスエントリにアクセスするたびに小さな「アンパック」を実行する必要があるため、変数len列をインデックスで使用しないでくださいnever 。
6位置
私はEAVや6NFの支持者ではなく、品質と基準の支持者です。私の立場は：
常に、あらゆる方法で、あなたが知っている最高水準であなたがしていることは何でもしなさい。
リレーショナルデータベース（私にとっては5NF）の場合、第3正規形への正規化は最小限です。 DataTypes、宣言的参照整合性、トランザクション、正規化はすべてデータベースの重要な要件です。それらが欠落している場合、それはデータベースではありません。
- 「パフォーマンスのために非正規化」する必要がある場合は、深刻な正規化エラーが発生し、設計が正規化されていません。限目。逆に、「非正規化」しないでください。正規化と正規化を学習してください。
余分な作業をする必要はありません。 5NFで要件を満たすことができる場合は、それ以上実装しないでください。オプションの値、またはDDLを変更せずに列を追加する機能、またはNull問題を完全に排除する機能が必要な場合は、6NF、それらを必要とするテーブルのみを実装します。
これを行う場合、SQLが6NFの適切なサポートを提供しないという事実だけのために、以下を実装する必要があります。
- シンプルで効果的なカタログ（列の取り違えやデータの整合性の喪失は単に受け入れられません）
- VIEWSを介した6NFテーブルへの5NFアクセスにより、ユーザー（および開発者）を邪魔な（「複雑な」ではない）SQLから分離します。
- ユーティリティを作成または購入して、面倒なSQLを生成して6NFテーブルから5NF行を作成し、同じものを作成しないようにします。
- 測定、監視、診断、および改善します。パフォーマンスに問題がある場合は、（a）正規化エラーまたは（b）コーディングエラーのいずれかが発生しています。限目。いくつかの手順をバックアップして修正します。
EAVを使用することにした場合は、それが6NFであることを認識し、上記のように適切に実装します。そうすれば、プロジェクトは成功し、保証されます。そうでない場合は、犬の朝食が保証されます。
6.1 無料の昼食のようなものはありません
その格言は言及されていますが、実際には誤用されています。実際に深く適用される方法は上記のとおりです。6NF/ EAVの利点が必要な場合は、それを取得するために必要な作業（カタログ、標準）も進んで行う必要があります。もちろん、当然の結果として、あなたが仕事をしなければ、あなたは利益を得ることができません。データ型の「損失」はありません。値ドメイン;外部キー;チェック;ルール。パフォーマンスに関しては、6NF/EAVにはパフォーマンスのペナルティはありませんが、滑り止めの標準以下の作業には常にかなりのパフォーマンスのペナルティがあります。
7特定の質問
最後に。上記のコンテキストを十分に考慮し、それが小さなチームによる小さなプロジェクトであることを考えると、疑問の余地はありません。
- EAV（または6NF）を使用しないでください
- NullまたはNullable列を使用しないでください（パフォーマンスを低下させたい場合を除く）
- 共通の支払い列には単一の支払いテーブルを使用してください
- 各PaymentTypeの子テーブルには、それぞれ特定の列があります
すべて完全にタイプキャストされ、制約されています。
この「別のrow_id」ビジネスとは何ですか？鹿か鷲かを確認せずに、動くものすべてにIDを付ける人がいるのはなぜですか。 いいえ。子は扶養されている子です。関係は1：1です。子のPKは、共通の支払いテーブルである親のPKです。これは通常のスーパータイプ-サブタイプクラスターであり、差別化要因はPaymentTypeCodeです。サブタイプとスーパータイプはリレーショナルモデルの通常の部分であり、データベースや優れたモデリングツールで完全に対応されています。
確かに、リレーショナルデータベースの知識がない人は、30年後にそれを発明し、面白い新しい名前を付けたと思います。さらに悪いことに、彼らは故意にラベルを付け直して、自分のものだと主張します。少しの教育と専門家のプライドは、無知または詐欺を明らかにします。それがどれであるかはわかりませんが、それはそれらの1つです。私は確認しやすい事実を述べているだけです。
最後まで一緒にいてくれてありがとう。
A。コメントへの回答
A.1アトリビューション
「私はRMに忠実です」と述べ、「業界の巨人」に言及して、ITプロフェッショナルはそれが何を意味するのかを理解していると思いました。謙虚な謝罪。
- 私には個人的または私的なまたは特別な定義はありません。 definition（必須など）に関するすべてのステートメント：
- 正規化、
- 通常の形式、および
- リレーショナルモデル。
。
EFCoddおよびCJDateによる多くの元のテキストを参照してください（Webでは無料で入手できません）
。
最新の時間データとリレーショナルモデル by CJ Date、Hugh Darwen、Nikos A Lorentzos
。
そしてそれらのテキストだけ
。
"私は巨人の肩の上に立つ"
。
- 上記の実装（例：主観的、一人称）に関するすべての記述は、経験に基づいています。上記の原則と概念を、商業組織（サラリーコンサルタントまたはコンサルタントの運営）として、アメリカとオーストラリアの大規模な金融機関で32年以上にわたって実施しています。
- これには、標準以下または非リレーショナルの実装を修正または置換する多数の大規模な割り当てが含まれます。
。
- これには、標準以下または非リレーショナルの実装を修正または置換する多数の大規模な割り当てが含まれます。
- 6番目の通常の形式に対する帰無問題
タイトルに関連する無料で入手できるホワイトペーパー（define Null Problemだけではありません）は次の場所にあります。
http://www.dcs.warwick.ac.uk/~hugh/TTM/Missing-info-without-nulls.pdf 。
。
6NFの「一言で言えば」定義（他のNFで経験した人にとって意味がある）は、p6にあります。
A.2裏付けとなる証拠
- 冒頭で述べたように、この投稿の目的は、コミュニティへのサービスとして、このコミュニティに蔓延している誤った情報に対抗することです。
- 上記の原則の実装に関して行われた証拠を裏付ける声明は、特定の声明が特定された場合に提供することができます。そして、この投稿が応答である、他の人によって投稿された誤ったステートメントが同様に証明されるのと同じ程度に。パンの戦いがある場合は、競技場が水平であることを確認しましょう
これが私がすぐに手に入れることができるいくつかのドキュメントです（私はニュージーランドで割り当てられています、数日でより多くを提供します、顧客名は難読化されなければなりません）。
a。 大銀行
これは最良の例です。この投稿で明確な理由で実施され、目標が実現されたからです。彼らはSybaseIQ（DW製品）の予算を持っていましたが、プロジェクトが終了したときのレポートは非常に速かったので、必要ありませんでした。貿易分析の統計は、上記の私の5NFと6NFであることが判明したピボット拡張でした。コメントで尋ねられたすべての質問は、以下を除いて、ドキュメントで回答されていると思います。
- 行の数：
-古いデータベースは不明ですが、他の統計から推定できます
-新しいデータベース= 1億を超える20テーブル、10Bを超える4テーブル。b。 小規模金融機関パートA
パートB -肉
パートC -参照図
パートD -付録、インデックスの監査前後（インデックスごとに1行）
4つのドキュメントに注意してください。詳細なインデックスの変更を検査したい人のためだけの4番目。彼らは、地元のサプライヤーが廃業したために変更できなかったサードパーティのアプリに加えて、変更できるが変更したくない120％の拡張機能を実行していました。新しいバージョンのSybaseにアップグレードしたために呼び出されました。これははるかに高速で、さまざまなパフォーマンスしきい値がシフトし、デッドロックがほとんど発生しませんでした。ここでは、デッドロックを排除することを目的として（事前に保証されている）、dbモデルを除いてサーバー内のすべてを完全に正規化しました（申し訳ありませんが、説明しません）ここで、「非正規化」の問題について議論する人々は、これについてピンク色になります）。これには、別の投稿の主題である「パフォーマンスのためにテーブルをアーカイブデータベースに分割する」の逆転が含まれていました（はい、新しい単一のテーブルは、2つのこぼれたテーブルよりも高速に実行されました）。この演習は、MS SQL Server [書き換えバージョンを挿入]にも適用されます。c。 イェールニューヘイブン病院
それは彼らの教育病院であるイェール大学医学部です。何年もの間それらをサポートしてきました。 Sybase上のサードパーティアプリ。統計の問題は、指定されたテスト時間にのみスナップショットを収集していた時間の80％ですが、一貫性のある履歴がないため、新しい一貫性のある統計と比較する「前の画像」がありません。同じグラフでUnixとSybaseの内部統計を取得できる他の共同体を知りません。自動化された方法で。これでネットワークがしきい値になります（読者がそれが良いことだと認めていると信じてください）。
そもそも何か、それは公開のためにクリアされました。もっと後で。さて、「「非正規化」がパフォーマンスを向上させる」などの概念を裏付ける証拠をいくつか持っていきましょう。あなたの番です。
A.3長さ
- 長さや凝縮された性質についてはお詫びしません。注意力が短い人（犯罪はない、最近は現実になっている）、またはリレーショナルテクノロジーや用語に慣れていない人は、原文またはそのテクノロジーの支持者を参照する必要があります。
- 定義上、これにはWikiや、この投稿が返信するポスターなど、このテクノロジーを軽蔑する人は含まれません。象がガゼルを定義することは不可能です。そして、もし彼らがガゼルの寿命について仮定しているのなら、私たちは彼らの言うことに耳を傾けるべきではありません。
私の一番の原則は、理由もなく何かを再設計することではありません。それで、私はオプション1を選びます。それはあなたの現在の設計であり、それは確かな作業実績があるからです。
代わりに、新機能に再設計時間を費やしてください。
ゼロから設計する場合は、2番目に進みます。それはあなたが必要とする柔軟性をあなたに与えます。ただし、1番がすでに配置されて機能しており、これがアプリ全体の中心にあるため、クエリ、ストアドプロシージャ、ビュー、UDF、レポート、インポートの正確な内容を正確に把握せずに、大幅な設計変更を行うことにはおそらく注意が必要です。など、変更する必要があります。それが比較的低いリスクで実行できることである場合（そして適切なテストアラディが実施されている場合）、ソリューション2に変更する可能性があります。そうでない場合は、新しいより悪いバグが発生する可能性があります。
いかなる状況でも、このような目的でEAVテーブルを使用することはありません。それらはクエリとパフォーマンスにとって恐ろしく、柔軟性はかなり過大評価されています（毎日のパフォーマンスを犠牲にして、プログラムを変更せずに年に3〜4回新しいタイプを追加できるようにするかどうかをユーザーに尋ねてください）。
一見すると、オプション2（または3）を選択します。可能であれば、一般化します。オプション4はあまりリレーショナルではないと思うので、クエリが複雑になります。これらの質問に直面したとき、私は通常、これらのオプションに「ユースケース」を提示します。
-これまたはこの操作を行うとき、デザイン2/3はどのように動作しますか？