@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
シリアルNoによる懸賞応募について
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2004-11-09 23:30
どこに投稿すべきか悩んだのですが、システムの仕様・設計に
関連する質問だと考え、こちらに投稿させて頂きました。 最近携帯による懸賞応募で、商品に貼ってあるシリアルNoを 送信するタイプのものをよく見かけますが、 あれと同じものを実装したいと考えています。 ところが幾つか問題がありまして、お尋ねさせて頂きたいのです。 まず応募者から送られてきたシリアルNoについてですが、 それを受け付けるかどうかを判断する必要があると思います。 ・二重応募拒否(同じシリアルNoでの複数回応募禁止) ・無効シリアルNo拒否(適当に入力されたシリアルNoによる応募禁止) 上記の2つのチェックが必要で、二重応募の禁止は簡単ですが、 無効シリアルNoを判別するにはどうすれば良いのか悩んでいます。 思いついたのは、桁数のチェックとチェックデジットだったのですが、 これだけのチェックだけで果たして良いのでしょうか。 それとも、発行したシリアルNo全てをDBに保存しておいて、 送られてきたシリアルNoと比較した方がよいでしょうか? また、シリアルNoの発行についてですが、普通 応募システム側で発行するものなんでしょうか? それともほとんど印刷業者に任せてしまったりするんでしょうか? 懸賞システムの開発は初めてなので、色々と初歩的な質問が多くて 申し訳ございませんが、皆様のご意見をお聞かせ頂ければ幸いです。 何卒、よろしくお願い致します。 | ||||
|
投稿日時: 2004-11-10 11:59
ん〜巷で流行っている物がどのような方式を利用しているかは、全くわ
かりませんが... まず、ナンバリングといっても単純な連番では無いことは確かです。 一つの考え方として、生産拠点や生産ロット、日、発売地域・店とかの番号を数 字のどこかに組み込むなり何かをしていると思いますよ。確かに同じ地域・ 店とかでも複数発行しますから、どこかに連番に近いような番号部分はあるとは 思いますが、簡単にはわからないようになっているはずです。 (とは言っても桁が固定で、0〜9までの数字なのですべてを試す気 なら突破できるでしょうけど。アルファベットも加えるともう少し パターンは増えます。) このあたりの工夫が必要です。印刷に関しては、発行リストというものを 印刷会社に提示すれば印刷はしてくれますが、単純連番に比べて当然価格 は高くなります。 チェック方法については、発行枚数がそれほど多くなければ >それとも、発行したシリアルNo全てをDBに保存しておいて、 >送られてきたシリアルNoと比較した方がよいでしょうか? でも良いかと思いますが、採番仕様を上記のように決めておけば、その 規則に従っているか、各意味を持たせた部分の数字の範囲は正しいかど うかのチェックでも可能でしょうね。後は2重応募のチェックで。 まぁ、一番のポイントは、シリアル番号を入手していない人が、でたらめに 入力しても、当たる確立を下げる(または採番規則をわかりにくくする) かということですかね。 | ||||
|
投稿日時: 2004-11-10 19:37
Beatleさん、返信ありがとうございます。^^
う〜ん。。。 やっぱり、商品コードや地域といった情報が含まれている可能性はありますよね。 実は、シリアルナンバーを生成できる印刷ソフトを見つけたのですが、 そのソフトでは以下のような項目が設定できるようになっていました。
これにチェックデジットを+する感じでやってみようかとも思ったのですが・・・ シリアルナンバーに意味のある数値が含まれているとなると、 設定が難しくなりそうですねぇ。 ここら辺の情報もう少し詳しく分かる方がおられたら、 アドバイスお願いします。<(_ _*)> しかしやっぱり、システム側にシリアルナンバーを生成して CSVで吐き出すような機能が必要そうだなぁ。。。 | ||||
|
投稿日時: 2004-11-10 20:08
どこまで情報を入れ込むか?によって作り方は変わるでしょうが、
・連番→暗号化→ユーザが受け取るシリアルNo. という形式だと暗号プログラムと復号プログラムの2本を作れば番号の管理は どこまで発行したか?という数字をひとつ持つだけで管理ができます。 あとはこれの応用ですね。暗号強度はシリアルNo.の価値に応じて複雑にすることが 必要になりますけど。 ちなみにユーザ向けのシリアルNo.はMSの製品表記を見ても分かる様に、 ひとつひとつが短く、かつ、間違い難い文字を使う工夫は必要でしょう。 [ メッセージ編集済み 編集者: m.ku 編集日時 2004-11-10 20:36 ] | ||||
|
投稿日時: 2004-11-11 12:07
永井です。一応、そういう関係の開発に関わったことがありますが……あまり詳しい内情を話すと怒られちゃいますので、一般論で。
まず「二重応募拒否」は実装されるとのことですので、そちらから話を展開させていただきます。 「二重応募拒否」の実装なのですが、DBを用いて簡単に実装するとなると、大きく2つの方法があると思います。 1. 使用された発行Noを詰め込むテーブルを用意して、Unique制約でチェックする 2. 全ての発行NoをDB上に持ち、使用済みフラグで管理する 1の方法を用いた場合、運用中のレスポンスはどんどん劣化していきます。そのシステムが使われれば使われるほど顕著になります。 これはあまり好ましい状態でないと思われるため、2が無難でしょう。 2を選んだ場合、アレクさんがご自分で書かれているように、これを同時に不正Noチェックの機構に流用出来ることになります。また、このチェックは非常に厳密で明快です。 以上より、「DBに全ての発行Noを持って、それと突き合わせる」をお勧めします。 以下余談です。 「発行Noにどこまで情報を入れ込むか」に関してですが、これは「絶対必要であるもの以外はなるべく内包しないことが好ましい」となると思います。 情報の絶対量が多くなれば、それは単純にデータ長や複雑性に反映されてしまい、必然、扱い難いものになると思われるからです。バーコード等の形式で発行して、機械を通したシステムへの入力を採用する……のならまた話は違ったりするのかも知れませんが。 で、この問題に関しても「DBに全ての発行Noを持つ」は有効です。全ての付帯属性を発行No内ではなくシステム本体に持つことが出来るため、発行Noのデータ絶対量が「想定発行数に必要な枠」「構造的な必然を入れ込むための枠」「不正に対する強度のための枠」の3つだけに拠る、つまり最低限に抑えられるからです。 「構造的な制約から必然である枠」というのは、例えば「複数拠点で任意にUniqueな発行Noを生成出来なければならない」などです。この場合「全部で10桁あるうちの最初の2桁は工場固有にしましょう」などとして、実質は残りの8桁を使って発行することになります。一般流通商品のバーコードに含まれる国番号やメーカー番号などのイメージですね。 ----- あと、ついでなので自分が実装したときの失敗談を……。 「全ての発行NoをDBに持つ」としたとき、「発行NoはUniqueで不変」だということでDBの主キーにしちゃったんですね、発行システムで。 いざ「発行Noをシステム外部に出力しよう」としたときに……出力を任意件数に区切る方法を思い付かなくて、性能問題を発生してしまいました。数十万件程度なら問題なかったんですが、数百万件とか発行されてしまいまして……数時間かかりました、発行Noをファイルに出力するだけで。 [ メッセージ編集済み 編集者: 永井和彦 編集日時 2004-11-11 12:26 ] | ||||
|
投稿日時: 2004-11-11 23:41
実際的なアドバイスをありがとうございます。^^
お返事が遅くなってしまって申し訳ございません。 皆様からのアドバイスを参考にさせて頂いた結果、 連番を暗号化→シリアルNo生成→全ての発行NoをDBに登録 といった形で実装してみることにしました。 ただ一つ心配なのは、全てのNoをDBにINSERTしなければならないので、 シリアルNoの数が大量になると処理に非常に時間がかかるということです。 これは仕方ないことなんでしょうか? それとも皆さんがいつも用いておられる効率的な方法が何かありますか? | ||||
|
投稿日時: 2004-12-19 16:32
例えば、チェックプログラムが有効なシリアルかどうかチェックする際に、 チェックディジットのみのチェックと、DB内を検索してチェックするパターンとは 処理そのものが違いますよね。 既に登録があったシリアルNOで際登録があった処理を予想すると チェックディジットの場合 1. チェックディジットをチェックする→結果OK 2. DBにINSERTする→登録済みエラー DBでチェックするパターン 1. シリアルそのものをDBから検索する→登録済みエラー チェックデジット等ですと、「存在しないシリアルNO」を意図的に 作り出すことも可能ですよね。 確実性か考えると、DBの中にはいっているほうがよいですね。 確かにINSERTは大変かもしれませんが。 そこまで厳重にチェックしなくていいよ。という場合でしたら、 DBなんて使わないほうがコストパフォーマンス的にもよいですけども。 | ||||
|
投稿日時: 2004-12-20 01:13
シリアル数が膨大になっても、
常にDBにシリアルを登録し続ける訳ではないでしょうし、 件数が増えたら登録に時間がかかるのは仕方がないとしても、 それは運用開始前の処理であって、 運用に対する影響は発生しないのではないでしょうか。 |