人間関係とソーシャル・メディア

どうも
こんばんわ
こんにちわ
オハヨウゴザイマスでス☆

今年、1発目の更新にして何年ぶり家の連日の更新えすね…。

ネタは愛も変わらず、「DB」でいきます！
今回はソーシャルゲームの特有のアクセス数などを考慮した設計段階を考慮します。

＜ソーシャルゲームって＞
１：ユーザー数がめっちゃ多い
これは使用するプラットフォームによもよるが一般にGreeやらモバゲーやらでは1日で10万～ユーザーを越すこともざらにある。なのでDB設計とは別に実装部分でも工夫雨も必要である(この辺は技術論になる)

２：ユーザーIDをキーにした処理が多い
例えばアイテム付与。ユーザーIDを中心にする機能や処理が多いのでレコードが多い場合の工夫必要。

３：永続的なデータと一過性のデータに分類される
主に「既存の機能上の(ベース)データ」、「イベント特有のデータ」の２つに分類される
・例えばゲーム内の経験値やお金は永続的なベースになるデータ。
それとは別にイベントでのイベント対戦成績やイベント順位、獲得ポイント履歴などは一過性のデータ

４：整合性とバグが致命的になる
・無料のwebサービスと異なり、課金が関わってくるシステムなので、バグが血眼気的になる。
品質のハードルがかなり高い。
・課金が変わるので特に月初のダウンタイムが大きな損失


＜データ分類＞
１：マスターデータ
こいつは一回登録されたらおそらく２度と返納がないだろうデータ。
アイテムとかですね。

２トランザクションデータ
こいつは例えばアイテム使用やバトルアクションなど頻繁に更新されるもの。

３：ユーザーデータ
これは１，２を含む物。
ユーザーの情報が基本。名前、ニックネーム、HP、MPなど


＜データ詳細＞
ここでは各上記のデータを詳しく見ましょう

マスタデータの例題
アイテム：ID、名前、回復量、ダメージ量、攻撃力、守備力、価格
モンスター：名前、HP、経験値、MP、攻撃力、ID

という感じになっているが、データ構造が階層になっている
例えば・・・
アイテムと言っても・・・
▼攻撃アイテム
▼守備アイテム
▼回復アイテム
▼補助アイテム

という具合に階層があります。

これは例えば、
ストーリのあるゲームの順序にも、職業付きゲームにも同様のことが言えます。
ex:武闘家+戦士=バトルマスター、バトルマスター+パラディン=勇者

＜ユーザーIDをprimary keyに持つテーブル＞

Primary Keyは大抵の場合は・・・「ユーザーID」になります。

この場合には…
・Open Social APIで提供されるゲーム共通情報
・メイン情報
・イベント中のユーザー情報
・セッションデータなど

これらはレコード数は限定的なもの

しかし
PrimarykeyであるユーザーIDに何か+αが付属されるもの
つまりprimarykeyが2つ?必要になるもの
この場合は非常にやっかいになるとのころ

・所持アイテム：ユーザーID、アイテムID
・クエストID：ユーザーID、クエストID

という具合に重複する。
となるとレコード数が激増する。。。


とい感じで本日はここまででおｋ

• 
• 
• ツイート