SQL Server を使用しています。
一部の列がクエリで使用されていない列が多数あるテーブルがあります。
私の質問は、それらを blob または XML 列として 1 つの列に保存しないのはなぜですか?
やらない理由やデメリットはありますか？
質問する
1581 次
4 に答える
2
私は常に、データ ストレージの世界ではすべてがトレードオフであるとお客様に伝えています。RDBMS は、耐久性、分離、一貫性、原子性 (一般に ACID と呼ばれます) などを提供します。ただし、これには、かなり複雑で厳格なスキーマのセットアップとメンテナンスの要件、さらにはデータによってはパフォーマンスが犠牲になります。
自分自身 (または利害関係者) に尋ねる必要があるのは、そのデータが何のために必要なのか、どのような状況でアクセスする必要があるのか、そのような場合にデータを待機できる時間はどれくらいかということです。次に、次のようなすべてのソリューションの長所と短所を書き留める必要があります。
列を分ける
- 整合性、パフォーマンス、ストレージのために最適化されたリレーショナル ストレージ
- DBA の高いメンテナンス オーバーヘッド
- スキーマの変更は高価です
- 完全に ACID 準拠
文字列ブロブ
- 堅固なストレージ、自動的に読み取り/検索/変更するにはコストがかかる
- 単純なテーブル スキーマ
- データに構造が適用されていない
- データを見つけるのが非常に遅い
- 厳しく制限された ACID プロパティ
XML
- スキーマを適用できる柔軟なストレージ
- データを見つけるのが遅い、インデックスで改善できる
- 値を直接照会できます
- 制限付き ACID プロパティ
- 高いストレージ オーバーヘッド
現在、これは完全なリストではありません。言及されたポイントのいくつかは、あるプロジェクトにとっては利点であるかもしれませんが、別のプロジェクトにとっては欠点かもしれません. すべてのメリットとデメリットを理解したら、自分の状況に適した方法を見つけやすくなります。
于 2013-06-25T13:33:19.837 に答える
1
このデータの唯一の使用例がアプリケーション サーバーが全体を取得する場合、それは明らかに「複数の値」ではなく 1 つの値です。確かに、クライアント アプリは文字列をいくつかの部分に解析する必要がありますが、データベースは気にしません。
したがって、これを単一の列として格納することは非常に正当です。
ただし、コメントで次のように述べています。
「ほとんどの情報は、データベースと通信するアプリケーション サーバーによって使用されます。情報を保存して情報を取得する必要がありますが、ほとんどの列で結果をフィルタリングする必要はありません。」
「ほとんど」は「すべて」と同じではありません。データベースが列の内容についてある程度のインテリジェンスを実行する必要がある場合は、問題があり、実際には別の列 (必要に応じてキーと値のペア) または XML として格納する必要があります。
于 2013-06-25T16:31:14.120 に答える