62835


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

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

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

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


CC BY-SA 4.0
2020-02-05T10:33:59.753
62806
2020-03-10T01:19:32.613
2020-02-05T10:38:01.163
3060
34779
question
mysql データベース設計
同じ構造の別のテーブルを作るべきでしょうか


# 【回答】

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

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

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

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

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

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

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


CC BY-SA 4.0
2020-02-06T12:42:04.820
62835
2020-02-06T12:42:04.820
35558
62806
answer


例えば予定を検索する際に、`予定`と`別の予定`を同時に検索するような状況があり得るか検討してください。単純なWHEREでの検索だけでなく、別のテーブルとの結合や参照制約なども含まれます。

あり得るのであれば、1つのテーブルにするべきです。

単純な例では、1つのテーブルであれば

[code]

    SELECT * FROM `予定` WHERE ...
    
[/code]

ですむことが、`別の予定`テーブルを作ってしまうとできなくなります。

逆にこのような状況がないと言い切れるのであれば、1テーブルにまとめてはいけません。

* * *

> 「1テーブルにまとめてはいけません」と言い切る理由が知りたいと思いました

実務的には、例えばこのテーブルに関わるすべてのクエリに条件指定が必須でこれを漏らすとバグになる、という問題があります。

DB設計の大原則みたいな話ですし、DBでなくとも「異なる種類のものを1つにまとめる」のがよくないのは自明なことだと思います。

DBはプログラムの都合で考えるとたいていよくないことが起きるので、DBを扱うのであればDB設計委の基本は身につけておいた方がいいと思います。


CC BY-SA 4.0
2020-02-09T05:28:44.497
62898
2020-03-10T01:19:32.613
2020-03-10T01:19:32.613
5793
5793
62806
answer