2017-06-19 1 views
0

私はイベントのデータベースを設計し、それに関する多くの統計を追跡したいと思います。多くの値を持つレコードを格納するデータベースを設計する最も良い方法は何ですか?

オプション1

Eventsのための一つのテーブルを作成し、そこにすべての私の統計列を置きます。男性の数、女性の数、正体不明の性別の数、温度、その日、それは開始時と同様に、任意の戦いは、警察が呼ばれていた、となどが

クエリは非常に簡単になりselect * from events

オプション2

EventsEventsAttributesの2つのテーブルを作成します。 Eventsテーブルでは、ID、イベントタイトル、開始/終了時刻などの重要な情報を保存します。

EventsAttributes私はすべてのイベント統計情報を保存し、EventseventId外部キーを付けてリンクします。

クエリは次のようになります。

select e.*, (select ev.value from EventAttributes ev where ev.eventId = e.id and attributeType = 1) as NumberOfMale from Events e

を(attributeType == 1が男性の数を表すことになり)クエリは、オプション1と前方としてまっすぐではないことだろうが、私はそれを正しい方法を設計し、厄介なクエリで暮らしたいです。

どのような選択肢が正しいのでしょうか(なぜ私はデータベース管理者ではありませんが、興味があります)。

ありがとうございます。

+1

オプション1はこれに対処する典型的な方法のように聞こえます。オプション2はEAV(エンティティ属性値)のように聞こえますが、これは非常にまれにしか実装されない邪悪な反パターンです。エンティティのすべてのプロパティ(この場合はイベント)を保持する方法としてテーブルを考えてみましょう。イベント中に複数回起こる可能性のあるもの(警察、怪我など)のための追加のテーブルを検討することもできます。 –

+1

オプション2では、3番目のテーブルAttributeTypesを忘れてしまいました。このルックアップをアプリにハードコードすると、実際には悪いことになります。 –

+0

@RogerWolfそうです。私はそれに言及するのを忘れていた。 – HDoan

答えて

0

データベースの設計にはオプション2を使用することをお勧めします。

このオプション(2)では、データベースの正規化のベストプラクティスを適用します。

  • 最初は、重複データを最小限にすることである。

    は、データベースを正規化するための3つの主な理由があります。

  • 第二第三のクエリを簡素化することであるデータ変更の問題を

  • を最小化または回避することです。詳細については

は、オプションをサポートするために、この正規化されたデータベースに基づいて、あなたはビュー(クエリ)を作成することができ

Designing a Normalized Databaseを読む(1)。

このようにして、データベースは将来スケーリングの準備が整います。

更新:イベントとevent_attributes説明したよう:

あなたはeventAttributes1、eventAttributes2を取得するために貴重なオペレータのピボットと共通テーブル式(CTE)を使用することができます...

は、あなたのテーブルがあると仮定以下:

ピボット読み取りの詳細については
events 
    ---------- 
    # event_id 
    event_title 
    start_date 
    end_date 

    event_attributes 
    ------------- 
    #event_id 
    #att_type 
    att_value 

    # is primary key 

    -- using table expression (it's like a dynamic view) 

    with query as (
    select e.event_id, e.event_title,a.att_type, a.att_value 
    from events e 
    join event_attributes a on e.event_id =a.event_id 
    ) 
    select event_id , event_title, 
    [1] as eventAttributes1, -- list all eventAttributes1 numbered [1],[2],... 
    [2] as eventAttributes2 
    [3] as eventAttributes3 
    FROM query 
    PIVOT(SUM(att_value) FOR att_type IN ([1],[2],[3])) as pvt 

Using PIVOT

詳細についてはUsing Common Table Expressions

+0

私はオプション2を好きですが、データが 'id、eventName、eventAttributes1、eventAttributes2、...のように結合されるように効率的に2つのテーブルを照会するとどうなりますか? ' – HDoan

+0

オプション2は非常に複雑になりがちなEAVです。これは、データベース世界に比較的新しい人のために私がお勧めするものではありません。はい、正規化が最善の方法だと私は確信していますが、この状況にEAVが必要とは思われません。 –

+0

@Sean Lange、データベース世界で初めての方なら、すぐに熟練者になるでしょうし、将来大規模なデータでデータベースを正規化するのは複雑になります:)。 –

関連する問題