会社のブログログイン登録スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。1,601件2テーブル設計に関して判断に迷ってしまったので、ご意見を伺いたいです。前提として、基本情報を登録するための親テーブルがあり、それに紐づく任意の数の予定を登録できる子テーブルがあります。今回、それとは別に種別の異なる予定を登録できるようにする必要が生じました。現在のところ、予定の登録内容として必要な項目は既存の子テーブルと完全に一致しています。このような場合、同じ構造の別のテーブルを作るべきでしょうか。それとも種別の違いを区分値として、既存のテーブルにカラム追加するのみの変更とするのがよいでしょうか。今回の場合はそれぞれの種別で項目が追加になる可能性はほとんどないので、同じテーブルで区分値で分けてもよいのではと考えているのですが、いかがでしょうか。個の銅バッジ3親テーブルと既存子テーブルと新規に作成するかもしれない子テーブルの最大件数のオーダはどのくらいでしょうか。各テーブルの項目数の概数も知りたいところです。非機能要件に(※)よってちがう結果になるような気がします。23:52質問ありがとうございます。すみません、最大件数のオーダが指す内容がわからないのですが、作成されているデータ量としては、親テーブルが1万件で、親の25%ほどが平均3件程度の予定が登録されているので7500件程度です。新規子テーブルも同じぐらいのデータ量になると思います。親テーブルは30項目程度で子テーブルは10項目程度です。非機能要件は厳密に決まっておらず、遅くなければといったところです。新規子テーブルと既存子テーブルは同じ顧客です。今後新たな種別が増える可能性はかなり低いと思います。(投稿順)3【回答】どちらの方法もメリットデメリットがあります。それらの得失を考慮して、どちらの方法に決める必要があります。私ならリスクを考えて、新規にテーブルを追加するかもしれません。種別ごとにテーブルを追加するよりも自然だと思います。新規に開発する場合は悩まずにカラムを追加すると思います。【デメリット】そのテーブルに関するドキュメント、ソースプログラム、SQLをすべて修正する必要があります。バグ混入の心配もあります。試験もやり直さなければなりません。※viewを作ってしのげるかを考えるかもしれません。テーブルのレイアウトを変更する移行作業も必要です。今回はあまり考慮する必要がないようですが、データ件数が多い場合、移行作業の時間やサービスを停止する時間が増えます。場合によってはテーブル名を変えることになるかもしれません。「カラム追加」の方法よりもバグ混入が少ないと思います。一般論ですが、「追加」の方が「変更」や「削除」よりも影響範囲が小さいです。今回はあまり考慮する必要がないようですが、顧客毎のデータをバックアップしたいときはテーブルを分けた方が楽です。今回はあまり考慮する必要がないようですが、種別が増えた場合、種別の数だけテーブルが増えることになります。個の銅バッジ1それぞれの場合のメリット、デメリットをわかりやすく示していただき、ありがとうございます。上記を参考にさせていただき、今回はソースへの影響とそれに伴って発生する作業を考慮し、新規にテーブル追加で対応することにしました。記載していただいた以下の考え方などもとても勉強になりました。>そのテーブルに関するドキュメント、ソースプログラム、SQLをすべて修正する必要があります。バグ混入の心配もあります。>※viewを作ってしのげるかを考えるかもしれません。>一般論ですが、「追加」の方が「変更」や「削除」よりも影響範囲が小さいです。回答ありがとうございました。|3例えば予定を検索する際に、予定と別の予定を同時に検索するような状況があり得るか検討してください。単純なWHEREでの検索だけでなく、別のテーブルとの結合や参照制約なども含まれます。あり得るのであれば、1つのテーブルにするべきです。...ですむことが、別の予定テーブルを作ってしまうとできなくなります。逆にこのような状況がないと言い切れるのであれば、1テーブルにまとめてはいけません。「1テーブルにまとめてはいけません」と言い切る理由が知りたいと思いました実務的には、例えばこのテーブルに関わるすべてのクエリに条件指定が必須でこれを漏らすとバグになる、という問題があります。DB設計の大原則みたいな話ですし、DBでなくとも「異なる種類のものを1つにまとめる」のがよくないのは自明なことだと思います。DBはプログラムの都合で考えるとたいていよくないことが起きるので、DBを扱うのであればDB設計委の基本は身につけておいた方がいいと思います。個の銅バッジ1回答ありがとうございます。横断的に検索する必要があるときは、1つのテーブルが良いと結論できそうで、重要な観点だと感じました。今回は「予定と別の予定を同時に検索する状況」はなさそうです。「1テーブルにまとめてはいけません」と言い切る理由が知りたいと思いました。|この質問に回答するには、ログインする必要があります。求めていた回答ではありませんか?mysqlデータベース設計のタグが付いた他の質問を参照する。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。従って情報を開示できることに同意したことになります。選択した項目のみ受け入れる。