H31 午後1問1設3(2)削除する属性について
SEさん
(No.1)
多段階抽選方式に対応する際に、参加申込みの抽選結果を削除する旨の記載があります。
多段階抽選のそれぞれの抽選結果を保持するためのエンティティを追加するため、参加申込みに抽選結果を持たずになくてもシステムとして成り立つのは分かります。
ただ、参加申込みの抽選結果を残したままのほうが、実際に開発する上での性能・可読性・開発効率面においてメリットがあると考えます。
最終的な抽選結果を取得する場合、参加申込みの後続エントリ枠番号を利用して再帰的に取得が必要となりますが、
そもそも、再帰SQLを利用する場合、
・システムバグ・データ補正ミス等により誤った値が設定されるとループが発生してしまう
・SQLが複雑化し、可読性・性能が劣化する
といったリスクがあります。(皆さんもご存じだとは思いますが…)
参加申込みの抽選結果は「最終抽選結果」という意味合いで残しておくことで再帰的に取得する必要がなくなりますので
開発面において、性能・可読性等においてメリットがあります。
残しておけば、その大会での抽選した会員について非常にシンプルなクエリで取得が可能ですし、
抽選した場合、あるいは、最終抽選(後続エントリ枠番号がNULL)で落選したタイミングで参加申込みの抽選結果に設定すればよいだけです。
こういった実開発の観点は無視して、重複管理を避けるというのがこの試験では重要視されているのでしょうか?
(確かに、アプリケーション設計のスキルを問う試験ではないですが・・・)
多段階抽選のそれぞれの抽選結果を保持するためのエンティティを追加するため、参加申込みに抽選結果を持たずになくてもシステムとして成り立つのは分かります。
ただ、参加申込みの抽選結果を残したままのほうが、実際に開発する上での性能・可読性・開発効率面においてメリットがあると考えます。
最終的な抽選結果を取得する場合、参加申込みの後続エントリ枠番号を利用して再帰的に取得が必要となりますが、
そもそも、再帰SQLを利用する場合、
・システムバグ・データ補正ミス等により誤った値が設定されるとループが発生してしまう
・SQLが複雑化し、可読性・性能が劣化する
といったリスクがあります。(皆さんもご存じだとは思いますが…)
参加申込みの抽選結果は「最終抽選結果」という意味合いで残しておくことで再帰的に取得する必要がなくなりますので
開発面において、性能・可読性等においてメリットがあります。
残しておけば、その大会での抽選した会員について非常にシンプルなクエリで取得が可能ですし、
抽選した場合、あるいは、最終抽選(後続エントリ枠番号がNULL)で落選したタイミングで参加申込みの抽選結果に設定すればよいだけです。
こういった実開発の観点は無視して、重複管理を避けるというのがこの試験では重要視されているのでしょうか?
(確かに、アプリケーション設計のスキルを問う試験ではないですが・・・)
2024.10.12 01:11
SEさん
(No.2)
「性能・可読性・開発効率面」を考えるのであれば、最終抽選結果を取るためのビュー(か、マテリアライズドビュー)を用意すべき(=外部スキーマで考慮すべきこと)で、概念モデルの時点では考慮すべきでない というところでしょうか。
2024.10.12 01:25
返信投稿用フォーム
スパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。