1

我正在开发一个类似于 Wufoo 的应用程序，它允许我们的用户创建自己的数据库并使用自动生成的表单和视图收集/呈现记录。

由于每个用户都在创建不同的模式（一个用户可能有一个他们的棒球卡集合的数据库，另一个可能有一个他们的食谱的数据库），我们当前的方法是使用 MySQL 为每个用户创建单独的数据库，并拥有自己的表。换句话说，我们的 MySQL 服务器包含的数据库如下所示：

main-web-app-db（我们的 Web 应用程序包含用户帐户信息、计费等表）
user_1_db (baseball_cards_table)
user_2_db (recipes_table)
....

等等。如果用户想要建立一个新的数据库来跟踪他们的 DVD 收藏，我们将使用“create table ...”执行“create database ...”。如果他们在其中输入一些数据，然后决定要更改列，我们将执行“更改表 ....”。

现在，我在构建它的过程中走得越远，MySQL 似乎越不适合处理这个问题。

1）我首先担心的是每次请求都切换数据库，首先是我们的主应用程序的数据库进行身份验证等，然后是用户的个人数据库，这将是低效的。

2）我担心的第二个问题是单个 MySQL 服务器可以托管的数据库数量将受到限制。暂时假设这个应用程序有 500,000 个用户数据库，MySQL 是否设计为以这种方式运行？如果是一百万或更多呢？

3）最后，这种方法是否会成为支持和扩展的噩梦？我从未听说过以这种方式使用 MySQL，所以我确实担心这会如何影响复制和其他扩展方法等事情。

对我来说，似乎 MySQL 不是为了以这种方式使用而构建的，但我知道什么。我一直在将 MongoDB、CouchDB 和 Redis 等基于文档的数据库作为替代方案，因为对于这个特定问题，这种无模式的方法似乎很有意义。

任何人都可以提供一些建议吗？

4

2 回答 2

2

由于您将架构留给您的用户来决定，因此使用强制您定义架构的关系数据库是没有意义的。

使用NoSQL数据库。对堆栈溢出做更多的阅读。

什么是 NoSQL，它是如何工作的，它有什么好处？

基于文档的数据库与关系数据库的优缺点

什么是最好的面向文档的数据库？

于 2010-03-16T14:12:17.417 回答
1

像您描述的那样即时创建表格是一个非常糟糕的主意。支持架构更改将是一场噩梦。每次有人添加或删除一个字段时，您都必须运行一个ALTER TABLE ...命令，如果表中有数据，这不是一个快速操作，因为它基本上使用新的 scehma 创建一个新表并将所有数据移动到新的. 不要走那条路。

您可以在 MySQL 之上实现某种键/值存储而无需太多工作，或者使用Friendly之类的东西，但寻找合适的文档数据库可能是一种更简单的方法。

MongoDB将是我的选择，但有很多事情需要考虑，其他人可能会说 Cassandra 会更好。使用 MongoDB 很容易上手，使用起来感觉就像使用 SQL 数据库一样熟悉。它的索引或多或少相同，查询也没有太大的不同。最好的事情可能是您不需要 ORM，您的对象或多或少地存储在数据库中。读取和写入可以非常接近金属完成，而无需大量映射到对象和从对象映射。

于 2010-04-05T18:57:27.290 回答