同じ構造の別のテーブルを作るべきでしょうか


テーブル設計に関して判断に迷ってしまったので、ご意見を伺いたいです。

前提として、基本情報を登録するための親テーブルがあり、それに紐づく任意の数の予定を登録できる子テーブルがあります。  
今回、それとは別に種別の異なる予定を登録できるようにする必要が生じました。  
現在のところ、予定の登録内容として必要な項目は既存の子テーブルと完全に一致しています。

このような場合、同じ構造の別のテーブルを作るべきでしょうか。  
それとも種別の違いを区分値として、既存のテーブルにカラム追加するのみの変更とするのがよいでしょうか。

最初は種別が異なるデータを同じテーブルにするべきでないように思えたのですが、  
今回の場合はそれぞれの種別で項目が追加になる可能性はほとんどないので、同じテーブルで区分値で分けてもよいのではと考えているのですが、いかがでしょうか。




# 【回答】

どちらの方法もメリットデメリットがあります。それらの得失を考慮して、どちらの方法に決める必要があります。  
私ならリスクを考えて、新規にテーブルを追加するかもしれません。

### 【既存のテーブルにカラム追加する方法】

【メリット】  
種別ごとにテーブルを追加するよりも自然だと思います。もし新規に開発する場合は悩まずにカラムを追加すると思います。

【デメリット】  
そのテーブルに関するドキュメント、ソースプログラム、SQLをすべて修正する必要があります。バグ混入の心配もあります。  
試験もやり直さなければなりません。  
※viewを作ってしのげるかを考えるかもしれません。  
テーブルのレイアウトを変更する移行作業も必要です。  
今回はあまり考慮する必要がないようですが、データ件数が多い場合、移行作業の時間やサービスを停止する時間が増えます。  
場合によってはテーブル名を変えることになるかもしれません。

### 【新規にテーブルを追加する方法】

【メリット】  
「カラム追加」の方法よりもバグ混入が少ないと思います。  
一般論ですが、「追加」の方が「変更」や「削除」よりも影響範囲が小さいです。  
今回はあまり考慮する必要がないようですが、顧客毎のデータをバックアップしたいときはテーブルを分けた方が楽です。

【デメリット】  
今回はあまり考慮する必要がないようですが、種別が増えた場合、種別の数だけテーブルが増えることになります。




# 【回答】

どちらの方法もメリットデメリットがあります。それらの得失を考慮して、どちらの方法に決める必要があります。  
私ならリスクを考えて、新規にテーブルを追加するかもしれません。

### 【既存のテーブルにカラム追加する方法】

【メリット】  
種別ごとにテーブルを追加するよりも自然だと思います。もし新規に開発する場合は悩まずにカラムを追加すると思います。

【デメリット】  
そのテーブルに関するドキュメント、ソースプログラム、SQLをすべて修正する必要があります。バグ混入の心配もあります。  
試験もやり直さなければなりません。  
※viewを作ってしのげるかを考えるかもしれません。  
テーブルのレイアウトを変更する移行作業も必要です。  
今回はあまり考慮する必要がないようですが、データ件数が多い場合、移行作業の時間やサービスを停止する時間が増えます。  
場合によってはテーブル名を変えることになるかもしれません。

### 【新規にテーブルを追加する方法】

【メリット】  
「カラム追加」の方法よりもバグ混入が少ないと思います。  
一般論ですが、「追加」の方が「変更」や「削除」よりも影響範囲が小さいです。  
今回はあまり考慮する必要がないようですが、顧客毎のデータをバックアップしたいときはテーブルを分けた方が楽です。

【デメリット】  
今回はあまり考慮する必要がないようですが、種別が増えた場合、種別の数だけテーブルが増えることになります。

