

実務でテーブル設計を行っているのですが、初修なもので難航しているのでアドバイスいただきたいです。

具体的な内容はかけないので、例えになるのですが  
[![想定テーブル](https://i.stack.imgur.com/hQH17.png)](https://i.stack.imgur.com/hQH17.png)

上記のようなテーブルが存在しているんですが、事件の内容が増えるたびにほしい詳細情報が変わるのでカラムが増えるような現状です。

求められているのは時系列での事件の一覧性と、個々の事件の詳細を知りたいといったものです。どのような方策が考えられるでしょうか？アドバイスよろしくお願いします。


CC BY-SA 4.0
2019-04-05T05:22:44.550
53933
2019-04-05T12:53:57.113
29098
question
sql database sql-server
テーブル設計について


「ほしい詳細情報が変わる」ということですが、中身がころころ変わるようなテーブルでは、一貫性のあるデータベースになりません。

どのように事件に関する情報を整理するかが定まっていないという事だと思われますので、事件の報告などの実務に詳しい先輩に教えを乞うのが良いと思います。

事件の種類によって必須となる項目がある程度定まるかと思います。  
傷害、恐喝、殺人、事故だと「加害者」「被害者」「被害状況/加害状況」「死者数、怪我人数、緊急搬送人数」といったように主たるものをリストアップしていってはどうでしょうか。


CC BY-SA 4.0
2019-04-05T07:20:24.717
53941
2019-04-05T07:20:24.717
217
53933
answer


あくまで一例ですが、以下のようにテーブルを分けます。

> 事件( **事件ID** , 事件種別コード, 発生時刻)  
>  事件被害( **被害ID** , 事件ID, 被害種別コード, 被害名)  
>  事件種別( **事件種別コード** , 事件種別名)  
>  被害種別( **被害種別コード** , 被害種別名)

中身は以下。

> 事件種別・・・ひったくり/殺人/窃盗  
>  被害名・・・・かばん/さいふ/Aさん  
>  被害種別・・・盗難/損壊/死亡/負傷

「正規化」というキーワードで勉強してみてください。

まず、Fumuさんの仰る「情報を整理する」ことが最初に必要です。


CC BY-SA 4.0
2019-04-05T08:16:48.797
53945
2019-04-05T08:16:48.797
2238
53933
answer


> 上記のようなテーブルが存在しているんですが、事件の内容が増えるたびにほしい詳細情報が変わるのでカラムが増えるような現状です。

無理に RDBMS を使うより MongoDB などのドキュメント指向DB とかの方が合ってるかもしれませんね。  
ドキュメント指向DBでは、データを行列からなる表ではなく「ドキュメント」として管理します。

ドキュメントは JSON 形式で表現され、例えば次のようなデータになります。

[code]

    {
      "発生日時" : "2019/3/3 10:00",
      "発生内容" : "ひったくり",
      "取られたもの" : "かばん"
    }
    {
      "発生日時" : "2019/3/3 11:11",
      "発生内容" : "殺人",
      "死亡者" : "Aさん"
    }
    {
      "発生日時" : "2019/3/3 11:11",
      "発生内容" : "窃盗",
      "取られたもの" : "さいふ"
    }
    {
      "発生日時" : "2019/3/3 11:11",
      "発生内容" : "殺人"
    }
    
[/code]

登録時に、事前のスキーマ定義は不要なので ドキュメントごとに必要な項目を登録できます。

この状態で、「発生日時＝2019/3/3 11:11」のものを検索したり  
「発生内容＝殺人」のものを検索したり することができます。

ただ、RDBMSと比べて一長一短の部分はありますので、RDBMS の方が良い場合もあります。  
要件などを 確認して 目的に有ったものを 選んでください。


CC BY-SA 4.0
2019-04-05T08:27:28.970
53946
2019-04-05T12:53:57.113
2019-04-05T12:53:57.113
5008
5008
53933
answer


詳細情報のデータで検索(where による絞り込みなど)をしないことが確定しているのでしたら、

発生時刻: datetime  
詳細情報: json

のデータ型で作ってしまう、というのも一つの選択肢だと思います。

この設計のデメリットは、json
の中身にインデックスが貼れない場合が多い(データベースエンジンに依存)ので、中身に対して検索を行おうとすると、それがとても遅くなる、ということが挙げられます。


CC BY-SA 4.0
2019-04-05T09:06:08.020
53948
2019-04-05T09:06:08.020
754
53933
answer