質問するログイン新規登録
データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

設計

設計は、ソフトウェアやシステムを作る上での設計方針、仕様策定、アーキテクチャ選定などに関する投稿です。

Q&A

2回答

202閲覧

テーブルの共通項目の使用について

ystes123

総合スコア2

データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

設計

設計は、ソフトウェアやシステムを作る上での設計方針、仕様策定、アーキテクチャ選定などに関する投稿です。

0グッド

0クリップ

投稿2025/10/22 10:44

0

0

実現したいこと

データベースの項目によくある共通項目「登録者」「更新者」「登録日時」「更新日時」「削除フラグ」について相談させてください。

−−−−
報告書システムの改修案件
(改修内容)
・報告書の代理申請を行いたい
−−−−

設計者は代理申請かどうかデータで判断するために、テーブル項目「報告対象者」と「登録者」が一致していない場合、代理申請と判断する思想でした。

もともとの申請(通常申請)は「報告対象者」と「登録者」が一致するため、この思想でも問題ないのですが、
判定処理をテーブル独自(共通的な項目以外)のものを使用するのに違和感を感じました。

 *ここでいう「報告対象者」と「登録者」は一意のIDになります。

発生している問題・分からないこと

みなさんは違和感を感じるでしょうか?
また、この件について指摘する場合、どのように説明すればよいでしょうか。

該当のソースコード

特になし

試したこと・調べたこと

  • teratailやGoogle等で検索した
  • ソースコードを自分なりに変更した
  • 知人に聞いた
  • その他
上記の詳細・結果

違和感はあるが、上手に説明出来ない

補足

特になし

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

sk.exe

2025/10/23 03:59 編集

どちらかと言えば Q&A ではなく意見交換向きのご相談内容ではないかと思いますが…… > データベースの項目によくある共通項目「**登録**者」「**更新**者」「**登録**日時」「**更新**日時」「削除フラグ」 まず、ここでの「登録」や「更新」の対象とは何であるか(「〇〇を登録する」あるいは「〇〇が登録される」の「〇〇」に何が当てはまるか)という点を明確にされることをお奨めします。 「データベースの項目によくある」という文脈に沿うのであれば、一般的にそれは「そのレコード自身」を指しますが。 > 報告書システム > 報告書の代理申請 その「報告書」が具体的にどのような性質の文書なのか、また「報告書の(代理)申請」という手続きが具体的にどのような流れで行われるのかが不明です。 1. いつ、誰が、どのような内容の報告書を作成したのか。 2. いつ、誰が、どのような方法(手渡し、郵送、メール、電子申請など)を用いてその報告書を提出し、誰がそれを受け取ったのか。 3. いつ、誰が、その報告書に関する情報(上記 1 )や申請手続に関する情報(上記 2 )をテーブルのレコードとして登録(データ入力)したのか。 以上のようなイベントが発生するとして、それらを別個の事象として記録できるようなテーブル設計になっているのか、本件において主体となるイベントはどれなのか、といったことが分からない状況では、MaskedRider-Sys さんが覚えた「違和感」がどのようなものなのか、その原因となった要素(データの「構造」、データ更新の「仕組み」、列の名前と役割の齟齬(「表現」や「言い回し」)など)が何であるかを他者が察知することは困難だと思います。 > ここでいう「報告対象者」と「登録者」は一意のIDになります。 「報告対象者」と「登録者」はそれぞれどのような属性の人物であり、どのような形でそれぞれのIDを管理されているのでしょうか。 医療保険を例に挙げると、あらかじめ指定しておいた代理人(配偶者や親族など)が被保険者本人に代わって保険金を請求できる(保険金は被保険者本人が指定した口座に振り込まれる)という制度がありますが、この場合は当然「被保険者」と「保険金の請求を行なった人物」を区別した上、「被保険者本人から請求されるケース」と「指定代理人から請求されるケース」の両方に対応出来るようにしなければなりません。 今回のケースに置き換えるなら、被保険者が「報告者を作成した人物」(本人のみ)、保険金の請求者が「報告書を申請した人物」(本人または代理人)に相当するわけですが、少なくとも請求記録上においてその二者を分けて捉えること自体はおかしなことではないでしょう。 > 判定処理をテーブル独自(共通的な項目以外)のものを使用するのに違和感を感じました。 「その報告者を作成した人物とは別の人物が代理人として申請することが出来る」という要件を満たしているか、それを実現できるようなテーブル設計になっているかどうかこそが肝心なのであって、「テーブル独自(共通的な項目以外)のものを使用する」ことが適切であるかどうかは、あくまで個別に判断すべきことではないかと思います。
ystes123

2025/10/23 13:54

長文ありがとうございます。
guest

回答2

0

みなさんは違和感を感じるでしょうか?
また、この件について指摘する場合、どのように説明すればよいでしょうか

「データベースの項目によくある共通項目」というのは、システムやフレームワークによって自動で設定されるカラムやデータのことでしょうか?
もしそうであれば、これらは付帯情報(記録・監査・管理目的)として利用される、いわゆるメタデータであり、それを業務ロジックに利用することに違和感を覚えるのは理解できます。
業務ロジックの根幹や状態管理には、“業務用の専用カラム”を設けるのが原則だと思います。


例えば、システムのデータ移行などが発生した場合、この種の「共通項目」には "ikou" や "9999/12/31" のような、データ移行専用の値を入れて対応することがあります。
つまり、安易に「共通項目」を業務ロジックに利用すると、後々問題が発生することがあります。

また、現状では「通常申請」と「代理申請」しかありませんが、将来的に申請方式が増える可能性も考えられます。
このような拡張性を考慮するなら、「申請種別」や「申請方式」といった専用のカラムを追加して管理した方がよいでしょう。

投稿2025/10/23 00:47

neko_the_shadow

総合スコア2409

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

違和感の元は何でしょう?

みなさんは違和感を感じるでしょうか?

全く感じません

「データベースの項目によくある共通項目」というのも主観的なものさしであり、また、「代理申請」という項目もまあよくあるとは言えない項目なので、よくある項目だけで定義できるとも思えません。

投稿2025/10/22 14:23

TakaiY

総合スコア14648

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.29%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問