私は、ユーザーが独自のデータベースを作成し、自動生成されたフォームとビューでレコードを収集/提示できるという点で、Wufoo に似たアプリケーションに取り組んでいます。
すべてのユーザーが異なるスキーマを作成しているため (あるユーザーは自分の野球カード コレクションのデータベースを持ち、別のユーザーはレシピのデータベースを持っている可能性があります)、現在のアプローチでは MySQL を使用して、ユーザーごとに独自のテーブルを持つ個別のデータベースを作成しています。つまり、MySQL サーバーに含まれるデータベースは次のようになります。
main-web-app-db (ユーザー アカウント情報、請求などのテーブルを含む Web アプリ)
user_1_db (baseball_cards_table)
user_2_db (recipes_table)
....
等々。ユーザーが自分の DVD コレクションを追跡するために新しいデータベースをセットアップしたい場合は、「テーブルの作成 ...」を使用して「データベースの作成 ...」を実行します。何らかのデータを入力してから、列を変更したいと判断した場合は、「alter table ....」を実行します。
さて、これを構築していくにつれて、MySQL はこれを処理するのにあまり適していないように思えます。
1)私の最初の懸念は、最初に認証などのためにメインアプリのデータベースに、次にユーザーの個人データベースに、リクエストごとにデータベースを切り替えることは非効率になることです。
2) 私が抱えている 2 番目の懸念は、単一の MySQL サーバーがホストできるデータベースの数に制限があることです。このアプリケーションには 500,000 のユーザー データベースがあると仮定しますが、MySQL はこのように動作するように設計されていますか? それが100万以上だったら?
3) 最後に、この方法はサポートと拡張が困難になるのでしょうか? MySQL がこのように使用されているという話は聞いたことがありません。そのため、これがレプリケーションやその他のスケーリング方法などにどのように影響するか心配しています。
私には、MySQL はこのように使用するために構築されていないように思えますが、私は何を知っていますか? MongoDB、CouchDB、Redis などのドキュメント ベースのデータベースを代替手段として検討してきました。これは、この特定の問題に対するスキーマレス アプローチが非常に理にかなっているように思われるからです。
誰でもこれについてアドバイスを提供できますか?