H30 午後I 問2 (1)について
えるさん
(No.1)
お世話になります。掲題の設問の
W9の性能測定用データ設計・データ生成作業の直前の作業について教えてください。
並行できる作業を問う問題ですが、答えは直前作業はW1となっておりますが、
どうしてもW2としか思えないのです。
というのもデータを設計作成するにしても、制約を満たしたデータを設計、作成
しないと、テーブルには追加できないものとなってしまう可能性があると考えてしまうからです。
この手の問題が出てしまうと、確実に間違えてしまいそうなんですが、
何か、納得できる説明を頂ける方いらっしゃいますでしょうか?
W9の性能測定用データ設計・データ生成作業の直前の作業について教えてください。
並行できる作業を問う問題ですが、答えは直前作業はW1となっておりますが、
どうしてもW2としか思えないのです。
というのもデータを設計作成するにしても、制約を満たしたデータを設計、作成
しないと、テーブルには追加できないものとなってしまう可能性があると考えてしまうからです。
この手の問題が出てしまうと、確実に間違えてしまいそうなんですが、
何か、納得できる説明を頂ける方いらっしゃいますでしょうか?
2022.09.10 11:23
にゃんちゃんさん
★DB シルバーマイスター
(No.2)
関連する工程だけ抜粋、要約します。
W1:テーブル設計(CREATE TABLEの設計)
W2:制約設計(ALTER TABLEの設計)
W9:テストデータ生成
W10:テストデータロード
模範解答ではW2とW9は同時進行としており
えるさんとしては「先にW2で制約決めておかないと、W10でロードした際にエラーになるのでは?」
ということですかね。
今回は性能測定用のテストデータを生成するため
制約に合うデータだけを意図的に作って投入するのではなく
実際に発生すると思われるデータを投入することで
そもそも制約設計が正しいかどうかもテストできるようにしているかと思います。
W1:テーブル設計(CREATE TABLEの設計)
W2:制約設計(ALTER TABLEの設計)
W9:テストデータ生成
W10:テストデータロード
模範解答ではW2とW9は同時進行としており
えるさんとしては「先にW2で制約決めておかないと、W10でロードした際にエラーになるのでは?」
ということですかね。
今回は性能測定用のテストデータを生成するため
制約に合うデータだけを意図的に作って投入するのではなく
実際に発生すると思われるデータを投入することで
そもそも制約設計が正しいかどうかもテストできるようにしているかと思います。
2022.09.10 15:38
えるさん
(No.3)
にゃんちゃんさん、お忙しいところコメントありがとうございます。
おっしゃられる通り、制約のテストということであれば、
NGのデータがあってもおかしくないかもしれないですね。
性能測定と言われて、制約のテストを含んでいると深読みできるかどうか、やはり
自分は難しそうに感じてしまいます。
また、こうも思ってしまいました。
制約のテストをするなら、なおさら制約の設計が出来ていないと、
良いテストケースが作れないのではないかと。
自分にはきっと合わない問題と割り切るべきですかね、、、。
おっしゃられる通り、制約のテストということであれば、
NGのデータがあってもおかしくないかもしれないですね。
性能測定と言われて、制約のテストを含んでいると深読みできるかどうか、やはり
自分は難しそうに感じてしまいます。
また、こうも思ってしまいました。
制約のテストをするなら、なおさら制約の設計が出来ていないと、
良いテストケースが作れないのではないかと。
自分にはきっと合わない問題と割り切るべきですかね、、、。
2022.09.10 16:23
にゃんちゃんさん
★DB シルバーマイスター
(No.4)
データベースの性能測定というのが、データが全件正常に投入できる前提でパフォーマンスだけ測定すればいいということなのか?ですね。
僕は何となく全体的なテストを最初にしようとしているんかな、くらいに思ってましたが
実際はいわゆる単体テストというか、もう少しテスト対象を細かくして見ていく工程もありそうですね。
僕がこの問題を解くときに考えたのは
W1:テーブルの構造が分からないとテストデータ作れないなあ
W2~W6,W9:とりあえずこれでテストデータは用意できるから、その他こまごました設計は同時進行でいいなあ(※ここが問題の個所ですね)
W7:設計したSQL文を実行しよう、テーブルが作られるぞ!
W10:作ったテーブルにテストデータ投入しよう
W8:統計情報を更新しよう
W11:実行計画を確認しよう。索引探索になってるかな?
でした
実務はともかく、デスぺ試験的にはこのくらいの考え方でいいのかなと。
テストデータを作る際に、制約を見て作る・・・というのが経験ないので違和感ありますが
たしかに、パフォーマンスのテストをしたいということであれば、制約違反が確実に起こらないテストデータを用意したいというのも分かる気はします。
パフォーマンスだけのテストという観点でも
W1:テーブル設計
↓
いわゆるテーブル定義書ができている段階なので
この列は重複しないとか、この列は'1'~'3'まで値が入るとかが分かっている
↓
W2:制約設計(この列にはUNIQUE制約、この列にはIN('1','2','3')の検査制約を設定しよう)
W9:テストデータ設計(この列は重複しないデータにしよう、この列は'1'~'3'の値を入れよう)
ということで、必ずしもW2の情報からW9を作らなくてもいいのかなと思いました。
たしかに文章の流れと「性能測定」という言葉から、こっちが本来想定されているものな気がしてきました。
僕は何となく全体的なテストを最初にしようとしているんかな、くらいに思ってましたが
実際はいわゆる単体テストというか、もう少しテスト対象を細かくして見ていく工程もありそうですね。
僕がこの問題を解くときに考えたのは
W1:テーブルの構造が分からないとテストデータ作れないなあ
W2~W6,W9:とりあえずこれでテストデータは用意できるから、その他こまごました設計は同時進行でいいなあ(※ここが問題の個所ですね)
W7:設計したSQL文を実行しよう、テーブルが作られるぞ!
W10:作ったテーブルにテストデータ投入しよう
W8:統計情報を更新しよう
W11:実行計画を確認しよう。索引探索になってるかな?
でした
実務はともかく、デスぺ試験的にはこのくらいの考え方でいいのかなと。
テストデータを作る際に、制約を見て作る・・・というのが経験ないので違和感ありますが
たしかに、パフォーマンスのテストをしたいということであれば、制約違反が確実に起こらないテストデータを用意したいというのも分かる気はします。
パフォーマンスだけのテストという観点でも
W1:テーブル設計
↓
いわゆるテーブル定義書ができている段階なので
この列は重複しないとか、この列は'1'~'3'まで値が入るとかが分かっている
↓
W2:制約設計(この列にはUNIQUE制約、この列にはIN('1','2','3')の検査制約を設定しよう)
W9:テストデータ設計(この列は重複しないデータにしよう、この列は'1'~'3'の値を入れよう)
ということで、必ずしもW2の情報からW9を作らなくてもいいのかなと思いました。
たしかに文章の流れと「性能測定」という言葉から、こっちが本来想定されているものな気がしてきました。
2022.09.10 17:05
GinSanaさん
★DB ゴールドマイスター
(No.5)
テストデータを作る際は、DLLを見てPKとかexcelのセルの列名のとこの上に書いといて被らないように作りますね。いざ入れるときに失敗するとむかつくのでw
値は乱数でよければ
値は乱数でよければ
od -A n -t u4 -N 4 /dev/urandom | sed 's/[^0-9]//g'
をwsl上で件数分実行するだけです2022.09.10 20:09
返信投稿用フォーム
スパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。