6

サード パーティの Web サービス ポータルとの間で送受信される情報を格納するデータベースを作成する必要があります。送信する情報のフィールドは約 150 ありますが、そのうちの約 50 フィールドは正規化することで削除できます (たとえば、アドレス テーブルに保存できるアドレスは 3 セットあります)。ただし、これでも 100 列になる可能性のあるテーブルが残ります。

どちらを使用すればよいかわかりませんが、これを処理する2つの方法を思いつきました。

1 . 100 列のテーブルとアドレス テーブルへの 3 つの参照があります。

2 . おそらく 15 ～ 20 の個別の専用テーブルに分割します。

オプション 1は、結合が最も少ないため最も高速に思えますが、100 列のテーブルという考えは適切ではありません。

オプション 2の方が適切で、より管理しやすいチャンクに分割できますが、データベース スペースを節約することはできず、結合の数が増加します。データベース内のほぼすべての列に値があり、これらの列をこれ以上正規化することはできません。

私の質問は、この状況では、c.100 列を含むテーブルを使用することは許容できるのでしょうか、それともプレゼンテーションのために複数のテーブルに分割してみる必要があるのでしょうか?

注意:テーブル構造は、使用中に変更されることはありません。Web サービス ポータルの新しいバージョン用に新しいデータベースが作成されます。Web サービスのデータ構造を制御できません。

編集：以下の@Odedの回答により、データへのアクセス方法についてもう少し考えさせられました。実際には、部分的にではなく、全体にしかアクセスできません。たとえば、列 5 ～ 20 を定期的に返す必要はありません。

回答: Oded が投稿したコメントに基づいて、Oded の回答を受け入れ、決心するのに役立ちました。オプション 1 を使用することにしました。たとえば、テーブルの行全体ではなく、列 5 ～ 20 に定期的にアクセスしたい場合は、パフォーマンス上の理由から、列を個別のテーブルに分割することを検討します。

4

3 に答える 3

11

リレーショナル純粋主義者の観点から言えば、まず、テーブルに 100 個の列が含まれていても、それらが関連している場合は何も問題はありません。ここでのポイントは、正規化してもまだ 100 列あれば問題ないということです。

ただし、正規化する必要があり、その過程で 15 ～ 20 の個別の専用テーブルになる可能性が非常に高く、ほとんどのリレーショナル データベースの専門家は、より優れた設計であることに同意します (関連する更新/削除の問題でデータの重複を回避し、データ フットプリントを小さくするなど)。 ...)。

ただし、実用的には、測定可能なパフォーマンスの問題がある場合は、パフォーマンスを向上させるために設計を非正規化することが賢明な場合があります。ここで重要なのは、測定可能であることです。実際の問題が発生する前に最適化しないでください。

その点で、最初の設計として 15 ～ 20 個のテーブルのセットを使用する必要があると思います。

于 2013-05-31T11:02:27.357 に答える
3

MSDN から: SQL Server の最大容量仕様:

非ワイド テーブルあたりの列数: 1,024

幅の広いテーブルあたりの列数: 30,000

したがって、あなたの場合は100列で問題ないと思います。また、（同じリンクから）注意する必要があるかもしれません：

主キーあたりの列数: 16

もちろん、これはサービスのログとしてのみデータが必要な場合のみです。

サービスから読み取った後、データを維持する必要がある場合 -> 正規化の方が良いようです...

于 2013-05-31T11:09:43.630 に答える
1

より少ない列でテーブルを「管理」する方が簡単だとわかったが、たまたま管理しやすさを定義した場合 (たとえば、SSMS でテーブル データを見るときの水平スクロールが少ない)、テーブルを 1 対 1 で複数のテーブルに分割できます。正規化のルールに違反することなく関係を構築します。

于 2013-05-31T11:37:07.173 に答える