データベースを使うか設定ファイル(ロジックやクラス)で済ませるかの判断基準について

Question

例えば一匹ずつポケモンの種類を図鑑に登録するようなデータ構造を作るときにデータベースを使いますか。
データは２００いくか、いかないかくらいになると思います。また，その時,ポケモンの技のテーブルなどを作りますか？

ユーザー一人一人が捕まえたポケモンのデータをデータベースに登録するのであれば分かるのですが，固定数でスケールしないデータをデータベースに格納する実装ってどうなんだろうって思ったのですが,設定ファイルや継承クラスにデータ構造を記述したほうが、保守しやすい気がします。そういう実装のプログラムを見たので普通にやられてることなのかなと疑問に思ったので質問しました。

かと言ってその後，ポケモンが随時増えていくとなると,参照構造の変更(データの順序が変わるなど)に対してシステムがロバストじゃないという点を除いて，数が1000とか2000とか増えるのであればデータベースを利用したら悪いという理由も特段ないような気もするので，速度もkey-valueストアならそこまで問題にならない(さすがに文字列参照より速くはないと思いますが)気もします。ただオブジェクト指向に慣れている身としては,ちょっと違和感があります。
ちなみに初期値のステータスしか変わらないくらいならハッシュやyamlで{"poke1":{attack:10,deffence:20...}"poke2"...}などで設定ファイル作れば十分な気もします。

皆さんはこういうときどういう実装しますか？

Answer 1

maisumakunさんの意見に同意です。

意味のもたないデータ集合であるならばDB化するメリットが全くありませんが、
意味を持つデータ集合であるならば、
リソースに制約があるとか、
DBMSを導入できないとかよっぽどのことがなければデータベース登録する方が良いと思います。

データ増減が少ない場合だとしても、
マスタ的な用途で利用されるならマスタ系テーブルとして追加することで、DB側でチェックを有効にできるというメリットがあります。(外部キー制約、UNIQUE制約、CHECK制約など)

データ整合性が破壊される不具合が、
一番調査にも時間がかかり厄介なので、
DB提供機能で防御できる部分は防御するのが一番安心ですかね。

また人によってはデータベースをデータ永続的に保存できるファイルの延長上という理解に止まっている方がいますが、
データベースの本当のメリットって、

• 人が見て判るようにデータ集合をテーブルなどを用いて分類可能
• それぞれのリレーションも保存できる
• 各種制約を用いることでビジネスルールを表現できる

僕自身は上記の3点のメリットも知っておいて欲しいなという思いはありますね。

Comments

[退会済みユーザー]

なるほど。納得しました！
昔アルバイトしてた時に凄くテーブルが多くて関連の薄いデータをあちこちに散乱し過ぎる設計の機能拡張をやったことがあって管理が大変だったことからテーブルを増やし過ぎることによる負の側面を感じていたのですが設計が綺麗であればメリット大きいですね。
他の方も良い回答いただいて勉強になりましたがデータベース特有の制約条件をデータ構造に付加できるという視点が目から鱗だったのでベストアンサーにさせていただきます。

Answer 2

自分の感覚としては、テキストのみで何にも結びつかないようなデータは別として、たとえば47個しかない都道府県でもDBに立ててしまう方です。

というのも、データベースにデータを入れることで外部キー（FOREIGN KEY）が使えるようになるからです。データベースレベルで紐付かない値をブロックしてくれるので、「整合性のないデータはそもそも入ってこない」という安心感は何物にも代えがたいです。

Comments

[退会済みユーザー]

なるほどリレーションが捕らえやすくなるからですね。
レコードがほとんど削除される可能性がないようなデータ構造であれば解りやすいというメリットはありますね。

Answer 3

例えば、それの利用範囲が広いならデータベースにする
という判断はできそうな気がします。
極端な例だと、別のプログラミング言語で(そのシステムを)
再構築する場合はデータベースの方がラクですよね。

まあ、どちらを選択するにせよ、利用するとこを
抽象化しといて、いざとなったら切り替えられる
ようにしとくのはよい選択だと思います。

Comments

[退会済みユーザー]

確かにデータベースでデータ構造保持しておけば別の言語で同じ実装出来るメリットは大きいですね。
ありがとうございます！