HOME»データベーススペシャリスト掲示板»H31  午後1問1設3(2)削除する属性について
投稿する

H31  午後1問1設3(2)削除する属性について [0824]

 SEさん(No.1) 
多段階抽選方式に対応する際に、参加申込みの抽選結果を削除する旨の記載があります。
多段階抽選のそれぞれの抽選結果を保持するためのエンティティを追加するため、参加申込みに抽選結果を持たずになくてもシステムとして成り立つのは分かります。
ただ、参加申込みの抽選結果を残したままのほうが、実際に開発する上での性能・可読性・開発効率面においてメリットがあると考えます。

最終的な抽選結果を取得する場合、参加申込みの後続エントリ枠番号を利用して再帰的に取得が必要となりますが、
そもそも、再帰SQLを利用する場合、
・システムバグ・データ補正ミス等により誤った値が設定されるとループが発生してしまう
・SQLが複雑化し、可読性・性能が劣化する
といったリスクがあります。(皆さんもご存じだとは思いますが…)
参加申込みの抽選結果は「最終抽選結果」という意味合いで残しておくことで再帰的に取得する必要がなくなりますので
開発面において、性能・可読性等においてメリットがあります。

残しておけば、その大会での抽選した会員について非常にシンプルなクエリで取得が可能ですし、
抽選した場合、あるいは、最終抽選(後続エントリ枠番号がNULL)で落選したタイミングで参加申込みの抽選結果に設定すればよいだけです。

こういった実開発の観点は無視して、重複管理を避けるというのがこの試験では重要視されているのでしょうか?
(確かに、アプリケーション設計のスキルを問う試験ではないですが・・・)
2024.10.12 01:11
 SEさん(No.2) 
「性能・可読性・開発効率面」を考えるのであれば、最終抽選結果を取るためのビュー(か、マテリアライズドビュー)を用意すべき(=外部スキーマで考慮すべきこと)で、概念モデルの時点では考慮すべきでない  というところでしょうか。
2024.10.12 01:25
返信投稿用フォーム
お名前
顔アイコン

本文(コミュニティガイドライン⇱を順守して適切な投稿を心がけましょう)
🔐投稿削除用のパスワード
投稿プレビュー
※SQL文は全角文字で記載してください。
※宣伝や迷惑行為を防止するため、当サイト、姉妹サイト、IPAサイト以外のURLを含む文章の投稿はできません。
投稿記事削除用フォーム
投稿No. パスワード 
© 2016-2024 データベーススペシャリストドットコム All Rights Reserved.

Pagetop