SQLでスキーマをどんどん増やしていいのか。

Question

Webアプリの保存データをMySQLで保存しようと考えています。
アプリで名前を付けて保存すると、MySQLサーバーに保存されるような感じです。
エクセルやワードで名前を付けて保存するように、
このような場合、
1つの保存ファイルとして、スキーマを増やしていくのはあまり良くないでしょうか？

1つの保存ファイル(スキーマ)内には、複数個のテーブルがあります。
そのテーブル内には数百のレコードがあります。

例:ブログ記事
Aさんのブログ(スキーマ)
投稿管理(テーブル)
→ 投稿日時、ブログ内容(レコード)

フレンド(テーブル)
→ フレンドID(レコード)

Comments

[maisumakun]

「データベースを増やす」とありますが、実際に増やすものはスキーマ・テーブル・レコード、あるいはどれでもないものでしょうか。

あと、マイクロソフトに「SQL Server」という製品があるので、「SQLサーバー」という表現は紛らわしくなります。「DBサーバ」あるいは「MySQLサーバ」としておきましょう。

[m.ts10806]

データベースの用途や要件を具体的に書いてください。ざっくりしすぎると赤の他人にはなにも伝わりませんし、的確なアドバイスは得られません。
(あと、ひとつ前の質問と関連性があるのでしょうか？いずれにしても未解決のまま放置はよろしくないです)

Answer 1

1つの保存ファイルとして、データベースを増やしていくのはあまり良くないでしょうか？

管理がやりづらくなるのでお勧めしません。

「1つの保存ファイル」が具体的にどんなものかにもよりますが、１レコードとして保存するのが妥当かと思います。

例:ブログ記事
Aさんのブログ(スキーマ)
投稿管理(テーブル)
→ 投稿日時、ブログ内容(レコード)

今回の場合、スキーマは全体で1つで問題ないと思います。

投稿管理テーブルに誰の投稿なのかを表す「ユーザーID」カラムを追加すれば、１つのテーブルで複数ユーザーの投稿を管理できます。

例:ブログ記事
Aさん、Bさん、Cさん、・・・のブログ(スキーマ)
投稿管理(テーブル)
→ ユーザーID、投稿日時、ブログ内容(レコード)

Comments

[退会済みユーザー]

ありがとうございます。
ということは、スキーマ、テーブル数を固定にして、全てのユーザーのデータを同じテーブルに追加していくということですね？

[nskydiving]

そういうことです。
回答に少し追記しましたので、ご確認ください。

[退会済みユーザー]

ありがとうございます。とても参考になりました。

Answer 2

よほど特殊な事情がある場合を除いて、運用に連れてスキーマが増えていく構造はアンチパターンに区分されるようなものです。

SQLアンチパターン 第8章 Metadata Tribble(メタデータ大増殖)の解説

Comments

[退会済みユーザー]

スキーマを保存ファイルごとに分けた方が、レコード検索やファイル管理が扱いやすくなるかと思ったのですが、あまり良くないようですね。
ありがとうございます。

[Orlofsky]

であれば、ひとつのテーブルにスキーマ(ユーザー)カラムを追加していくのが一般的な運用でしょう。
スキーマ毎に個々にテーブル作っていたら、複数のユーザーにまたがる集計とか面倒ですから。

[退会済みユーザー]

ありがとうございます。
なるほど。たしかにスキーマが別ですと、集計ができないですね。
ちなみに、中身が集計の必用がない完全に個々に独立したデータな場合。スキーマをどんどん増やしていくことはやめておいたほうがいいと思われますか？
管理しづらいという点は置いておいて。

Answer 3

データベースが壊れた時に備えて、定期的にバックアップを取得し、データベースが壊れたらリカバリします。
バックアップと復元

Comments

[Orlofsky]

ディスクの空きがあるかも確認も忘れずに。ディスクを増設するなりクラウドに移行するとか。

[退会済みユーザー]

ご回答ありがとうございます。
データベースというのはスキーマのことでして、説明がおかしくてすみません。