ウェブリ/ブログログイン

]

トップ  プロフ  フレンド  サークル

２月に某イベントで、人気投票をリニューアルしたいという話がありました。 それで私はいろいろ考察したり、設計書を書いたのですが、 反応がないですし資料的に勿体無いので、公開しようかなと思い今日に至りました。 資料的は要件定義から基本設計くらいまで、設計書にすると１０個ぐらいになります。 ☆資料 企画書 要件／機能一覧 プラットフォーム定義書 ユースケース 画面遷移１（必要なもののみもっと肉付けが必要） 画面一覧 画面遷移２ プロト画面 画面項目 アトリビュートリスト エンティティリスト ユーザ／グループ一覧 ユーザ／グループ権限マトリクス CRUD定義書（未完了） ER図（T-ER）・アプリケーション ER図（簡易版）・アプリケーション ER図（権限） データベース物理設計書 DDL クラス図 ☆設計思想<2006/08/06追記> 私の目標としているところは、同日に１イベントだけで使われるシステムではなく、 同日に複数のイベント（１０イベントぐらい）で、利用可能なシステムを想定して作成しました。 この設計の一番の特徴は、ＥＲ図をT字型ER図ライクで作成したことです。 そのため、票を数えるということにUpdateなんて無粋なことはしません。 一般、サークル、スタッフの投票は全て各イベント、各回数に対して キャラクターに一票を投じるという思想を持って設計されています。 そのため、票を数える場合は全てにおいてSelect Count(PrimaryKey) From Tableで 票を数え、それを各イベントのポイント（１位、２位、３位）と演算します。 （もちろん、サブクエリが使用できれば、SQL１回で取り出し可能です。） はっきりいって重いかもしれません。ただ、この仕組みで構築すると票を削除するときに 確実、簡単に減らすという利点があります。 （投票をした人の票を削除する場合は、投票した人の票をdeleteするだけで 無用なトランザクションが発生しません。） また、同時に1000人が投票をしてもテーブルのカラムに対して、Updateするのではなく、 テーブルにInsertするので、ここでもトランザクションが発生しないという利点が あります。 ただ、レスポンスが重い場合は、サマリーテーブルを作成するなどのチューニングが 必要になります。イベント開催中に参加者へ公開するといっても１分おきに公開すれば いいと思います。１分おきにサマリーバッチを実行し、情報を収集すれば問題は解決します。 そうすれば情報を表示する側は、そのサマリーした情報を表示するだけで 済むわけですから、レスポンスは最適な状態になると思います。 結果、投票は速くトランザクションが発生しない、票を削除してもトランザクションが 発生しない、情報公開のレスポンスも速いシステムになり、同時複数イベントに 耐えることができると思っています。 ※注意１ 資料のER図には、権限周りのテーブルは入っていません。 というか、まだ？作成していませんのであしからず。 ユーザ／グループ権限マトリクスあたりを見れば、想像はできると思います。 ※注意２ 画面遷移も完全な形になっていません。これは本来ユーザとの話し合いの中で どのように遷移するかを決めるべきものです。これは七々見が機能として想像し 最低限人気投票に必要な機能を図解したものに過ぎません。

<< 前記事（2006/08/02）

トップへ

後記事（2006/08/06）>>

<< 前記事（2006/08/02）

トップへ

後記事（2006/08/06）>>