Q&A
回答ではなく、質問になってしまうのでこちらに書かせていただきます。
> ・「ユーザー」は「他ユーザー」の情報を利用することはありません
例えば管理画面でユーザ一覧を表示するようなこともないのでしょうか？
マスターデータの扱いは？別DBにする又は同じデータ・テーブルを各ユーザDBに持たせる？そもそもマスターデータを持たない？
今作っているアプリケーションで以下のようにユーザーごとにDBを区切る方式で作っています
調べたところMYSQLにDB数の上限はなくHDDの空き容量とファイルシステムの上限の限り作ることが可能とのことです
しかしこの設計を友人に相談したところ、そんな設計は聞いたことがないと一蹴されました
この設計は間違っているのでしょうか
・「ユーザー」は「他ユーザー」の情報を利用することはありません
mysqlで、ユーザーごとにDBを分ける場合のメリットとデメリットは以下の認識なのですが
なにか認識が足らない部分、間違っている部分などございましたらご指摘いただきますと嬉しいです
[ユーザーごとにDBを区切る方式]
ユーザーA：DB_A
ユーザーB：DB_B
ユーザーC：DB_C
ユーザーD：DB_D
[DB.TABLEは同じでユーザーごとにユニークキーで区切る方式]
DB.TABLE
ユーザーA：ユニークキー=A
ユーザーB：ユニークキー=B
ユーザーC：ユニークキー=C
ユーザーD：ユニークキー=D
[ユーザーごとにDBを区切る方式]のメリットは
・検索に関して一部ユーザーが大量の情報を登録しても、他のユーザーは影響をうけにくい
[ユーザーごとにDBを区切る方式]のデメリットは
・バックアップ、DB構造変更などの管理がやや面倒になる
[ユーザーごとにユニークキーで区切る方式]のメリットは
・バックアップ、DB構造変更などの管理が簡単
[ユーザーごとにユニークキーで区切る方式]のデメリットは
・検索に関して一部ユーザーが大量の情報を登録したら検索速度に影響が出る（インデックスを張っても遅くなる量だった場合）
デメリットが管理面だけであれば
ソフトウェアでなんとかできそうです。
以上、お忙しい中恐縮ですが
ご確認よろしくお願い致します
ありがとうございます
開発者側（私達側）は利用することがあると思いますが
ユーザー側は、ログイン時を除き、自身に割り振られたDB以外の情報を利用することはありません
回答4件
0
しかしこの設計を友人に相談したところ、そんな設計は聞いたことがないと一蹴されました
この設計は間違っているのでしょうか
よほど特殊な状況（インデックスという概念のないBigQueryを使うなど）でない限り取らない設計です。
・検索に関して一部ユーザーが大量の情報を登録したら検索速度に影響が出る（インデックスを張っても遅くなる量だった場合）
当該ユーザーに対してはテーブルを分けようが分けまいが遅くなりますし、それ以外のユーザーに対してはインデックスがあれば実用上問題ありません。
投稿2019/06/03 08:42
総合スコア146018
回答ありがとうございます、一般的でない設計なのは理解いたしました
特殊であるが、メリットもなければ（教えていただきありがとうございます）、デメリットも管理面以外は特にないのでしょうか
テーブルを分ける大きなデメリットとして、「ユーザーを超えた集計クエリを回すのがほとんど不可能になる」ということがあります。
「ユーザー（DB）を超えた集計クエリが不可能に」
それはUNIONを使えば可能なのではないかと思います
テーブルを分ける弊害は、「SQLアンチパターン」という本にも上がっています。
https://qiita.com/Aiita/items/1eda0a10a6aa305379b5 （本を参考にまとめた記事）
アンチパターンありがとうございます
URLに書かれている情報は「DB」ではなく「テーブル分割」のお話なので少し状況は違いますが
お教えいただいたURLには私が求めている新たな問題は見当たりませんでした
また、「アンチパターン＝絶対にやってはいけない」ということではなく有用な場合もあると思っています
なぜなら世界的に使われているワードプレスなどはEAV(Entity Attribute Value)だからです
>1.テーブルの増殖
管理面のお話でした、私が想定していたものです。
>2.データの整合性を管理する
DBごとに管理する方式のため可能性は低いです
>3.データの同期
DBごとに管理する方式のため可能性は低いです
>4.一意性の保障
DBごとに管理する方式のため可能性は低いです
>5.テーブルをまたいだクエリ実行
DBごとに管理する方式のため可能性は低いです（別のユーザーの情報を利用することがない場合）
>6.メタデータの同期
管理面のお話でした、私が想定していたものです
>7.参照整合性の管理
DBごとに管理する方式のため可能性は低いです（別のユーザーの情報を利用することがない場合）
>8.メタデータトリブル列の特定
管理面のお話でした、私が想定していたものです
動的にDDLを投げる設計は、セキュリティ面やACID面からも懸念事項が多いです（特に、MySQLではCREATE TABLEは強制的にトランザクション外となってしまいます）。
…というより、速度面の「メリット」がほとんど存在しない以上、テーブルを分ける方式にはデメリットだけが存在する、ということになってしまうかと思うのですが、それでも分ける設計を取りたい理由は何でしょうか？
>CREATE TABLEは強制的にトランザクション外となってしまいます
上記情報ありがとうございます！調べてみます
>それでも分ける設計を取りたい理由は何でしょうか？
はい、こういった構造にしなければならない理由はあるのですが
ユーザーごとにDBの構造を柔軟に変更できるようにしたい、かつNoSQLは使いたくない
その条件を提示してしまうと「それ以外の選択肢はないじゃないか」と議論が終わってしまうので
その構造の私の知らないデメリット、否定的なご意見や情報が欲しいです
あの、今までの議論は何だったのでしょうか。
これまでは、あくまで「同じ構造でテーブル/データベースを分ける」という前提で話を続けてきたので、そこを覆されると議論が全く無意味になってしまいます。
ごめんなさい、私としましては期待する情報を得ることが出来ました
・同一のDB.tableにしても何行増えようとインデックスを貼っていれば他ユーザーは全く影響を受けない
・CREATE TABLEは強制的にトランザクション外となる
0
ベストアンサー
ユーザーごとにDBを区切る方式]のメリットは
・検索に関して一部ユーザーが大量の情報を登録しても、他のユーザーは影響をうけにくい
どんな影響を想定されているのでしょうか？
DBMSは殆どそれらを考慮して設計されています。
[ユーザーごとにDBを区切る方式]のデメリットは
・バックアップ、DB構造変更などの管理がやや面倒になる
肯定しますが、どれだけ大変なのか理解されていますか？
[ユーザーごとにユニークキーで区切る方式]のメリットは
・バックアップ、DB構造変更などの管理が簡単
とんでもないです。自動化するなら、ユーザーの増減を考慮した仕組みを組み立てなければなりません。
[ユーザーごとにユニークキーで区切る方式]のデメリットは
・検索に関して一部ユーザーが大量の情報を登録したら検索速度に影響が出る（インデックスを張っても遅くなる量だった場合）
テーブルを分けるんだから、他のユーザーには影響しませんよね。
複数のユーザーに対して検索するというならUNIONクエリーなどになるでしょうからその通りです、
そもそもunionクエリーになる状態は、正規化されていない状態です。
テーブルをユーザー毎に分けるというなら、パーティショニングの方がましです。
そもそも、デメリットよりメリットの方が大きいと思われているようですけど、逆だと思いますよ。
追記
質問を盛大に勘違いしていました。
ユーザーに対してサービスの提供を行うという類のものなら、当然他のユーザーによる影響でサービスの質の低下が無いように考えるのは当然ですね。
メリット/デメリットよりサービスの質を最優先すると、「ユーザーごとにDBを区切る方式」しかないように思います。
投稿2019/06/03 09:18
編集2019/06/04 02:11
総合スコア25327
>どんな影響を想定されているのでしょうか？
>DBMSは殆どそれらを考慮して設計されています。
ありがとうございます、インデックスを貼っていれば
他ユーザーは全く影響を受けない旨理解いたしました
>肯定しますが、どれだけ大変なのか理解されていますか？
はい、DBの構造変更などは
管理用のソフトウェアを作ることで解消できると考えていますが
なにかその他にある場合はご教授下さいますと嬉しいです
>とんでもないです。自動化するなら、ユーザーの増減を考慮した仕組みを組み立てなければなりません。
そうですね
>複数のユーザーに対して検索するというならUNIONクエリーなどになるでしょうからその通りです、
>そもそもunionクエリーになる状態は、正規化されていない状態です。
すみません前提条件を書き忘れておりました
「ユーザー」は「他ユーザー」の情報を利用することはありません
つまり、UNIONを使ってなにか情報を出したいのは開発者側であるので
それが正規化されてないか否かは重要ではないです
>テーブルをユーザー毎に分けるというなら、パーティショニングの方がましです。
>そもそも、デメリットよりメリットの方が大きいと思われているようですけど、逆だと思いますよ。
すみません私の読解力なさがお恥ずかしいのですが
「DBを分けること」に対する「デメリット」が、教えていただいた情報から具体的になんなのかよくわかりませんでした
要点としてはなにが問題となりそうなのでしょうか
（私の勘違いでちょっと失礼なコメントだったので削除します）
ちょっと質問を勘違いしていたみたいです。
DBを分けると言われてますね。
ログインさせるDBを分ける情報をまた別DBにするとか、マスターなどは共通のDBにするというような、プログラムの共通部分はDBに持ち込まないような設計にする必要はありますね。
ありがとうございます、
そのほかに懸念する点、思いつきましたらお教えくださいませ
0
DB単位でアクセス権の管理が切り分けしやすいので
サーバー１台で複数部門で利用するときなど
管理者以外のアクセスはDB単位でユーザーを分けたほうが管理しやすいし
情報統制しやすいでしょう（個人情報の管理とか含む）
ただ、同じサーバー上のデータは連携して使う前提になっていたりして
結局rootもしくはそれに近いスーパーユーザーを利用して
アクセスするような管理になりがちなので、わざわざDBをわける意義が
あまりないかもしれません。
投稿2019/06/03 08:59
総合スコア116724
前提条件を書き忘れておりましたが「ユーザーA」は「ユーザーB」の情報を利用することはありません
そうですね、おっしゃる通りでユーザーごとにDBへのアクセス制限をかけると
メリットとしてよりセキュアな環境が作ることが出来ますね。。
ご意見ありがとうございます、そのほかデメリットも思いついたら教えて下さいませ！
0
メリット・デメリットの回答ではないのですが、
プログラムだけ共用した個別システムを作るという意味なら、複数の顧客企業にサービスを提供する会社では採用されていますね。ASP。
SaaSという言葉が登場したときに、ASPとどう違うんだ？という話になり、（私の理解では）複数顧客企業で同じシステムを使うのがSaaSで、新規顧客が獲得できた度に別のシステムを立ち上げるのがASPという整理になったと思います。
投稿2019/06/03 14:35
総合スコア85901
あなたの回答
tips
プレビュー
