somemo programming etc.

プログラマ、雑記、プログラミング関係はLinkから、数式はこっちでまとめていることが多い

【設計】【データベース】

現在、改修の都合上、DBテーブルのPKを増やさなくてはならない状況です。結論を先に言うと、PKが1つから3つに増えます。しかし、一意に絞るだけならシーケンスで済みそうです。

前提条件

以下の条件です。

  • ユーザが存在する
  • ユーザはサービスを提供している
  • サービスには基本サービスと、基本サービスに紐づく追加サービスが存在する
  • ユーザは、色々な申請を行うことができ、申請には、どんな申請であるかを示す区分がある
  • 申請の区分には、サービスに対する変更申請を行うことができる
  • 変更申請時に申請情報と、申請に対する詳細情報が作成される
  • 1回の変更申請につき、1サービスしか変更できない

要件

1回の変更申請につき、複数サービスの変更をできるようにすること。これにより、前述のPKを増やす問題が発生します。

データ構造

前提条件よりデータ構造は以下のような感じです。

ユーザ
├基本サービス1
│├追加サービス1-1
│└追加サービス1-2
│
├申請1(サービス変更)
│└変更申請詳細(基本サービス1)
│
└申請2(サービス変更)
 └変更申請詳細(基本サービス1-1)

それぞれのPKについて

  • ユーザ:ユーザID
  • 基本サービス:基本サービスID、FKとしてユーザID
  • 追加サービス:追加サービスID、FKとして基本サービスID
  • 申請:申請ID、FKとしてユーザID
  • 変更申請詳細:申請ID

変更申請詳細は、「1回の変更申請につき、1サービスしか変更できない」という条件があるので申請IDだけがPKです。加えて、サービスを特定する基本サービスIDと追加サービスIDをもつ。しかし、基本サービスに対する変更の場合は、追加サービスIDはデータとしてNULLである。

問題点

今回の要件により「同じ申請IDのデータが存在しなくてはならない」ため、「申請IDでの変更申請詳細を特定が不可能」になります。つまり、「PKを変更する」必要があります。

変更案

シーケンス(または、オートインクリメント)の採用になると思います。

それぞれのPKについてで述べた「サービスを特定する基本サービスIDと追加サービスIDをもつ。しかし、基本サービスに対する変更の場合は、追加サービスIDはデータとしてNULLである」という条件から、追加サービスIDをPKにできません。

変更申請詳細のデータ作成時に、追加サービスIDを0以下のNULLでない値にすれば可能です。ただし、追加サービスIDはPKであるため、FKにはできなくなります(PKとして0以下をもっていないため)。

その他

またあとで。