1

TIMES と呼ぶ db テーブルがあります。これは伝統的に次のようなものです。

ID    Blah1 Blah2 Blah3  Description
1     a     b     c      Day
2     d     e     f      Night

(Blah 列を追加したのは、主に、テーブルに存在する列が他にもたくさんあることを示すためですが、これらは、行おうとしているアップグレードには直接関係しません。)

データベースから取得した結果に言語サポートを追加したいと考えています。したがって、私の提案は次のいずれかでした。

a) 怠惰な道をたどって、言語用の新しい列を追加するだけで、

ID    Blah1 Blah2 Blah3  Description  Language
1     a     b     c      Day          English
2     d     e     f      Night        English
1     a     b     c      Tag          German
2     d     e     f      Nacht        German

または、できれば、b) 正規化を行い、関連する値だけの新しいテーブルを作成します。

ID      Description  Language
1       Day          English
2       Night        English
1       Tag          German
2       Nacht        German

DB担当者は、元のテーブルを使用して、すべてをxmlに含めることができると言いました...そうすれば、行を節約できます。

ID        Blah1 Blah2 Blah3  Language
1         a     b     c      <TimeDescriptions>
                                 <TimeDescription language='English'>
                                     Day
                                 </TimeDesciption>
                                 <TimeDescription language='German'>
                                     Tag
                                 </TimeDesciption>
                             </TimeDescriptions>        
2         d     e     f      <TimeDescriptions>
                                 <TimeDescription language='English'>
                                     Night
                                 </TimeDesciption>
                                 <TimeDescription language='German'>
                                     Nacht
                                 </TimeDesciption>
                             </TimeDescriptions>

「行を保存」？私は実際にはdbの男ではありませんが、それは私には奇妙に聞こえます. 確かに、それはいくつかの行を節約します...しかし、行自体がはるかに長い場合、それは全体的に勝利ですか? （非常に可能性があります）それ以上に、私が慣れ親しんでいる正規化のルールに違反しているようです。また、SQL で XML を使用して検索できることも知っています (私はそれを行ったことがなく、詳細については非常に漠然としています) が、これで勝てるとは思えません。

私がそれについて尋ねているとき、彼はチクチクし始めたので、私は後退しましたが、何かが足りないかどうか知りたい. 明らかに多くの詳細が欠けていますが、詳細な分析を求めているわけではありません...これが合理的である可能性があるかどうかを知りたいだけです.

編集：ああ。あなたは、私が正しいフォーマットを学ぶのに十分長い間ここにいたと思うかもしれませんが、私はどういうわけかその最後のビットを台無しにしています.私はそれを修正しようとしますが、他の編集は大歓迎です.

4

1 に答える 1

2

確かに、それはいくつかの行を節約します...しかし、行自体がはるかに長い場合、それは全体的に勝利ですか?

おそらく。ただし、これはページに収まる行数が少なくなることを意味し、通常はディスク アクセスとディスク I/O が増えることを意味します。これらの行はそれほど悪くはないように見えますが、12 の言語をサポートしている場合、XML データだけで 1 行あたり 1Kb になることになります。大まかな計算のための私の経験則は、1 ページあたり 8Kb を使用することです (これは、dbms に応じて調整できます)。したがって、1 ページあたり 8 行しか得られません。

また、like 句を使用して行をクエリすることWHERE Description = 'Day'ははるかに困難です。(ただし、これはアプリケーションでは問題にならない場合があります。) また、既存の構造では、必要に応じて「言語」でテーブルを分割できます。

元のテーブルに新しい列を追加すると、4NF に違反する多値の依存関係が発生するようです。(言語->>説明) しかし、それを複合属性としてモデル化できれば、その依存関係をなくすことができます。

複合属性: 複合属性は、dbms が a) 完全に無視するか、b) ユーザーが部分を操作できるように関数と演算子を提供する内部構造を持つ属性です。最も一般的な例は、「日付」タイプの列です。日付には、年、月、日という内部構造があります。それらには、内部の多値の依存関係があります。しかし、dbms には、必要なときに断片を取得するための関数と演算子が用意されています。

dbmsでは、この機能を説明するために、複合、複合、ユーザー定義、タイプ、列、および属性という単語の組み合わせを使用する場合があります。

dbms がユーザー定義型をサポートしている場合、ロケール固有の単語の型を作成し、それをテーブルで使用できる場合があります。

しかし、いずれにせよ、これは意見の問題であってはなりません。代理キーを使用する 5NF アプローチ、代理キーを使用しない 5NF、複合型またはユーザー定義型を使用する 5NF、および XML を 1 日の午後または 1 日でテストできるはずです。次に、別の午後を費やして、インデックス作成とクエリが適切に行われていることを確認します。これにより、パフォーマンスの違いが単にミスや急いでいる、または無知によるものではなくなります。

最後に、最高のパフォーマーとメンテナンスのコストを比較検討します。(そして、これらの新しく取得したスキルで履歴書を更新してください。)

于 2013-01-14T12:19:04.870 に答える