0

私は、ユーザーが数千人 (または潜在的に数百万人) の人々に対して単一の選択を行うプログラムを設計しています。これをデータベースに保存する 2 つの方法を考えました。1) エントリごとに別の行を作成する、2) 新しい人物の選択肢を追加するか、既存の人物の選択肢を変更するだけの単一の長いテキスト。

エントリごとに個別の行を作成する方が効率的だと思いますが、たとえば数十万のエントリについて話している場合、そのクエリに対して見ているネットワーク オーバーヘッドと、単一の長いテキストとユーザーのCPUを使用してテキストを解析しますか?

例として、単一の長いテキストは次のようになります。

Data
[Person A:Choice A][Person B: Choice A][Person C: Choice C]...[Person n:Choice n]

複数の行は明らかに次のようになります。

Person    Choice
A         A
B         A
C         C
....
n         n

たぶん、そもそも私はこれを正しい方法で考えていません。このようなことを行うより効率的な方法はありますか？

ご意見ありがとうございます。

4

2 に答える 2

1

コメントを回答に入れ、場所を拡大します。

stringvsの決定についてTable。毎回テーブル。

Person (Id, Name)テーブル、テーブル、テーブルChoice (Id, Value)を基調としたデザインPersonChoice (Id, PersonId, ChoiceId)。インデックス可能で検索可能で柔軟なソリューションを提供します。

SQL でテキスト列のデータを非表示にすることは非常に悪い考えです。明らかにXMLデータとそのデータ型を無視します。しかし、それはここでは当てはまりません。

後日統計を追加するための 1 つの解決策は、スケジュールされた SQL エージェント ジョブをデータから実行して、いつ、どのような変更が行われたかを解析し、そのデータを別の「レポート」テーブルに格納することです。

何千もの行を保存して操作する手間を省くために、設計で考慮すべきことは、選択肢をグループ化するという考えです。(自分自身とサーバーの両方の) 作業を大幅に節約できます。

データベース設計の世界へようこそ！

于 2012-05-17T10:35:56.553 に答える
0

エントリごとに個別の行を作成する方が効率的だと思いますが、たとえば数十万のエントリについて話している場合、そのクエリに対して見ているネットワーク オーバーヘッドと、単一の長いテキストとユーザーのCPUを使用してテキストを解析しますか?

ネットワーク オーバーヘッド (2 つの設計の違いとして) は無視できます。基本的に、サーバーに送信するのはクエリだけであり、サーバーが返すのは結果セットだけです。クエリの結果が 1 行の場合、サーバーは 1 行のみを返します。クエリの結果が 10,000 行の場合、サーバーは 10,000 行を返します。

実際のオーバーヘッドは、サーバーでの実行速度とメンテナンスにあります。インデックスを使用すると、サーバーはテーブル内のインデックス付きの行をすばやく見つけます。しかし、「1, 2, 3, 5, 6, 7, 8, 10, 13, 17, 18, 30, 27」のような単一の値で 17 を見つける場合、おそらくインデックスは使用されません。

そのような値は、型の安全性と、外部キー参照とカスケードを使用する機能も失います。

于 2012-05-17T10:50:09.370 に答える