AA名簿DB計画

外部設計

※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

必要ページ

リストページ
- ソート機能：最終更新日・ＩＤ・種族・性別・年齢・ＰＬ名/それぞれ昇降順
- 表示：No・名前・年齢・性別・種族・ＰＬ名・最終更新日
  - アドベ時代みたいに画像うｐされてたら※とかつける　ってのあったら便利かなあ（bySirco）
  - 無くても良いけど、有ったら有ったで良い。位の印象かなぁ。私は＜※（by聖）
  - 聖さんに同じく。（きさらぎ）
  - じゃあなくてもいい　かな。処理的にそれほどでもないけど、あえて付けることでもないし……（bySirco）

新規登録ページ
- 基本設定
  名前/ふりがな/種族(プルダウン)/性別(プルダウン)/職業
- ステータス
  腕力/器用/敏捷/知力(全てプルダウン)/HP/MP/スキル/魔法/欠点
  - ステータスプルダウンはしなくてもいいかなあ、という気はする。入力面倒じゃない？今の（bySirco）
  - 記入の方が早いからそっちの方が良いかな。
    あと、合計８になってないと弾く機能が付くと登録間違いが減るかな？とか。要求に書くべきか。(by聖)
  - もしくは、「ステータス合計は８です」とか文字を表示させるにとどめるか。はじく機能つける場合ってPHPの動作になるのかな。可能であればつけられたら入力ミスも減るかも（きさらぎ）
  - はじく機能：
    $ステータス合計=$腕力+$器用+$敏捷+$知力;
    if($ステータス合計==8){とおす}else{はじく処理}
    で十分可能。ステータスエラー（上限下限限界突破している・合計値のミス）は関数にまとめておいたら便利そう。（迫）
- その他設定
  装備・所持品/経歴・外見・その他
- 追加
  セッション履歴・遭遇メモ/イベント履歴
- 画像アップロード
- ＰＬ領域
  ＰＬメモ/ＰＬ名/メールアドレス/ホームページＵＲＬ/パスワード

編集ページ
- 新規登録ページの内容にプラスして
  データの削除（パスワード入力＋チェックボックスにチェック）

個別ページ

検索ページ
- キーワード検索（複数検索
- 検索ボックスリセット

以下追加？

ユーザーログインページ
- ログイン用：メールアドレス・パスワード入力ボックス

ユーザーページ
- ＰＬ名/メールアドレス/パスワード/サイトURL　＜変更可能
- 稼働ＰＣ一覧
- 新規登録
- ＰＣの削除・冬眠もここで選択？

SQL処理部分

データベースとテーブルの作成・削除
ユーザー作成と権限付与
- これいるかな？
  DBオンリーではなくて、柔軟に動き回れるよう処理部分DB、表示部分PHPを考えていたのだけど　(bySirco)
- PHPで何処までできるか（技術的な意味も含めて）、をまったく考えないでSQLでできることをとりあえずあげてるので、利便性や操作性を考えてやりやすい方で。ユーザー作成は表示部分の方にはいるのかな？
  参考までに現行名簿がどうわかれてるか、リストアップしてもらえるとありがたいかも。というのはここじゃなくて相談に書くべきな気がする（きさらぎ）
- 把握＜SQLでできることをとりあえずあげてる
  ユーザ概念（PL単位での登録）を入れるかかな。今は完全にPC単位での登録のみで管理しているけど、ユーザ概念を入れれば要求定義にも追記した「冬眠」関係の処理、及び上限数確認がしやすいというのはあるからアリかなとも思うー(bySirco)
- えーと、＜参考までに現行名簿がどうわかれてるか、
  今は完全にPHPで処理してて一切DB使ってないお。(bySirco）
- 現行名簿仕様了解。引き続き、SQLで可能な操作をリストアップ予定（きさらぎ）
- ここで言うユーザー作成は、DBにアクセスしてSQLを操作するためのユーザー作成とそれに対する権限付与らしい。ので不要？（きさらぎ）
- その意味でのユーザ作成はいらないかな。最初の段階で一度作っちゃえばそれでいいかも。
  あって不便なものではないから、将来的に導入しやすくする（SiestaがAAの管理権を委譲する可能性は０じゃないから）意味で付けておいてもいいかなー程度。保留案レベル？（迫）
- この機能自体は手間取るものではないので、あとあとあらたなユーザー作成が必要であればすぐに追加可能。今のところは、DB管理用ユーザーの作成・権限付与さえ行えばそのあと特にはいらなさそう？（きさらぎ）
データ検索
バックアップ・復元
データ追加・更新・削除
カラムの作成・追加・削除
既存テーブルにフィールド追加
作成済みテーブルから新規テーブル作成
主キー追加
データベース一覧表示
トリガの作成
- テーブルに対してデータの追加や更新が行われた時に、自動的に別のSQL文を実行させるもの
ビューの作成
- テーブルから一部を取り出したものに名前を付け、独立したテーブルのように扱える。＝仮想テーブル。イベント時の表示処理が可能か？
- 正規化したテーブルからデータを取り出す際にはこの処理が必須。selectで取り出せば良い。カラム数が多いことから、おそらくメインの処理になると予想
バイナリデータ（画像ファイル）保存可能　データ型をBLOB型に設定
- PHPを使って、格納された画像ファイルを呼びだして表示も可能

必要項目

言語定義

登録PC
- 通常PC、及びイベントPC全てを含む。（冬眠（仮）処理を導入した場合、冬眠PCも含む。）
通常PC
- 通常名簿に登録されている冒険者PCをさす。
イベントPC
- ヴィランズなどのイベントにおいてのみ使用可能なPCをさす。
冬眠PC
- 冬眠（仮）処理を導入した場合、PC上限数に含まず、現在使用できないPCのこと。
  - なお、この処理の目的はPC名かぶり確認、及びPCステータスの保持/こぴぺのテマを減らす目的。

テーブル作成時の状況

ロウを作った段階では全てのカラムはnullにしておきたい。出来た……よね？
- 出来ます（きさらぎ）

【不動要素】

登録PC　常時必須項目

ID
1. いわゆるユニークID。全登録PC内で同一のものはない。接頭語なしの順ナンバーかな。
振り分けID
1. 通常PCか、イベントPCかの振り分けに使用する。
  1. 接頭は通常PCは「No-」、VILLAINシリーズは「Vx-」（VR-、VD-、etc.etc.）
  2. Noはなんばーじゃなくてのーまる。
名前
1. ふりがなは何となく残していたが不要な気もする。漢字表記はあくまでイレギュラー。基本カタカナでふりがなはナンセンス？　漢字表記であればメモ等に記載すればよい。
PCステータス
1. 稼動/冬眠/終了を振り分ける。（終了はイベントPCなどに影響？）
PC陣営
1. 冒険者/VILLAINS/囚人/その他...等。PCステータスと結合する場合は接頭語を含めるか。
登録日
1. 30日以内削除不可ルールの為に使用。基本的にはうわがかない。新規登録、稼動再開の際には上書き処理。
更新日
1. 更新時の時間を取得する。
PL情報
1. 今までは全部ばらばらにしていたけど、これくらいならまとめて<>区切りとかでカラム（だっけ？）にぶち込んで、PHP側で切り出すのもありかなー。
2. 内容は「PL名<>メールアドレス<>URL<>接続IP」かな。
種族
性別
年令
職業
1. 種族～職業、この辺をカラム分けするかどうかかなあ……ソートにも関るから、ここを切り分けておかないとPHP側でソートしてやらなきゃいけない。ソートとかはDBの得意分野だから……んむむむむー分けたほうが絞込みとかはしやすいんだろうけれど、やたらとカラムが増えるだけの気も。
能力値、MAXHP、MAXMP
1. 同じくまとめて<>区切りで入れてもいいかも。
  「腕力<>器用<>敏捷<>知力<>MAXHP<>MAXMP」とかね。
スキル
1. 文章要素が入るのでここは単独にしたほうがいいかも。
魔法
1. 内容emptyなら非表示　とかPHP側で操作してやるのもあり。かな。
欠点
1. スキルに同上。
経歴、外見、性格など
1. スキルに（ｒｙ
PLメモ
1. スキ（ｒｙ

保留不動要素

ひみつのしつもん
1. 今朝駅で思いついたけど、それほど難しいことではないかな。脆弱性には繋がるんだけど。ちとそこで悩み。

【追加要素】

通常PC

遭遇メモ
1. いわゆる「会った人メモ」。内容emptyなら非表示。イベントでは非表示か、任意表示？
セッション履歴
1. そのまま。内容emptyなら非表示。イベントでも非表示。
イベント履歴
1. 無数に増えていきそう。
  例えば2009.1段階でのフェスは（アドベを含めれば）「V2」だけだけど、2009.12段階では「V2」「VD」になるわけで。
  戦歴がある事を考えればそれぞれカラムを別にするほうがいいし。
  それぞれの「戦闘回数」「勝利点」等はPHP側で処理してやって、「戦闘回数<>勝利点<>戦闘履歴１<br>戦闘履歴２<br>戦闘履歴３...」ってカラムに入力する形かなあ。

イベントPC

思案中...

追加要素について

イベントごとにテーブル作るのが妥当かなあ．ヴィランズ４（仮）テーブルとか．項目はそれぞれカラムにわけたほうが検索もしやすいと思う（きさらぎ）

AA名簿DB計画

メニュー

リンク

他のサービス

外部設計

必要ページ

SQL処理部分

必要項目

言語定義

テーブル作成時の状況

【不動要素】

【追加要素】