5

現在、テーブルがあり、新しいデータ列の追加を開始する必要があります。すべてのレコード (新しいデータ列を追加した後に新しいデータを使用する場合でも) がデータを持つわけではありません。したがって、これは実際には一部のデータ行の拡張であり、すべての行に適用できるわけではないため、新しいテーブルにより適しているかどうか疑問に思っています。

つまり、これらの新しいデータ要素には未使用の列がたくさんあるので、これは新しいテーブルにより適しているように見えますか?

編集（これは制限が多すぎると考えました）

最初のテーブルはページ ビューのレコードです (現在 200 万レコード) - id - IP アドレス - 閲覧回数 - created_at タイムスタンプ - 日付

すべての IP アドレスについて、1 日ごとに記録が作成され、連続したページビューが 1 日あたりのビュー回数に追加されます

追加のフィールドは、起点追跡用です (つまり、Google アナリティクスのソース/メディア/キャンペーン)

すべての訪問でその情報が得られるわけではありません。行の約 10% にデータがあると想定します (通常、最初の訪問時にのみ起因するため)。

データの主な用途は、人々の出身地を特定することです。これは、より頻繁に使用されるようになる可能性があります (これは、単一のテーブルに適しているようです)。

フィードバックに感謝します - 必要に応じてさらに追加できます

4

2 に答える 2

10

基本的なルールは次のとおりです (より厳密な正規化ルールから単純化されています)。

属性/列が主キー全体に依存し、他に何も依存しない場合、それはテーブルに属します。

主キー以外に、または主キーに加えて依存している場合、それは別の場所に属しており、それが属しているテーブルは現在のテーブルとの関係を持っている必要があります。

たとえば、あなたの名前は SSN に依存するため、SSN が主キーである場合、あなたの名前はそのテーブルに属します。あなたの車または電話番号は、SSN に完全に依存しているわけではありません (複数の車または電話を持っている可能性があるため、別の表に記載されます (最初の表に主要な電話番号が記載される場合があります)。

データベースの設計について本当に学びたい場合は、selectコマンドの構文を忘れて、正規化について調べてください。他の人への私のアドバイスは、すべてのデータベース スキーマは 3NF で開始し、パフォーマンスのために必要な場合にのみ元に戻すことです。

そして、それを行うことに固有の問題を理解している (そして軽減している) 場合に限ります。

于 2012-05-25T12:46:35.983 に答える
1

ほとんどの列がデータ型であるvarchar場合、アプローチは問題ありません。

varcharデータ型は、テーブル セル内のコンテンツのサイズに応じてテーブル内のスペースを取るためです。

Sql サーバー 2008 を使用している場合は、新しい列を SPARSE として定義できます。

SPARSE カラムの長所と短所の詳細については、こちらを参照してください

于 2012-05-25T12:43:37.993 に答える