0

Microsoft SQL Server 2008 を検討してください

次のように 2 つの異なる方法で作成できるテーブルを作成する必要があります。

Structure Columnwise
StudentId number, Name Varchar, Age number, Subject varchar
eg.(1,'Dharmesh',23,'Science')
   (2,'David',21,'Maths')


Structure Rowwise
AttributeName varchar,AttributeValue varchar
eg.('StudentId','1'),('Name','Dharmesh'),('Age','23'),('Subject','Science')
   ('StudentId','2'),('Name','David'),('Age','21'),('Subject','Maths')

最初のケースではレコードは少なくなりますが、2 番目のアプローチでは 4 倍になりますが、2 列が削減されます。

では、パフォーマンス、ディスク ストレージ、およびデータの再試行の点でどちらのアプローチが優れているのでしょうか??

4

2 に答える 2

4

2 番目のアプローチは、一般にEAV設計として知られているエンティティ-属性-値です。

私見、ずっと最初のアプローチ。これにより、列を適切に入力してデータを最も効率的に保存できるようになり、クエリの容易さと効率が大幅に向上します。

私の経験では、EAV アプローチは通常、苦痛の世界を引き起こします。これに関する以前の質問の一例を、ベスト プラクティスへの適切なリンクとともに示します。検索を行うと、さらに多くの情報が見つかります。

人々が EAV の道をたどる一般的な理由は、柔軟なスキーマをモデル化することです。これは、RDBMS で効率的に行うのは比較的困難です。その他のアプローチには、XML フィールドへのデータの格納が含まれます。これは、NOSQL (非リレーショナル) データベースがスキーマレスな性質 (MongoDB など) により非常に便利になる理由の 1 つです。

于 2012-02-17T09:52:24.147 に答える
4

最初のものはパフォーマンスが向上し、ディスク ストレージとデータ取得が向上します。

  1. 属性名をvarcharとして持つと、名前やデータ型を変更したり、あらゆる種類の検証を適用したりすることができなくなります
  2. 目的の検索アクションをインデックス化することは不可能です
  3. 整数を varchar として保存すると、より多くのスペースが使用されます
  4. 整数の順序付け、加算、または合計は頭痛の種になり、パフォーマンスが低下します
  5. このデータベースを使用するプログラミング言語には、強い型付けされたデータを持つ可能性はありません

最初のアプローチを使用する理由は他にもたくさんあります。

于 2012-02-17T09:48:26.420 に答える