动态直接到数据库字段或“模拟”字段领域？
在 PHP/MySQL 应用程序上...
我们计划为用户提供创建简单数据库的能力。
假设它可以达到超过 10000 个主要用户帐户，几年后可能会增加数倍。 有效的方法是什么？
A) 将用户定义的表和字段直接创建到我们的应用程序的数据库中？ 那不是像...我们的约 40 个表格应用程序以及 10000 个用户创建的表格吗？
我知道在查询和使用等时它会很有效
B）有表和字段的表吗？ 就像...
- 表 usrtables
- tabID
- usrID
tabName
等
表usrfields
-tabID
-fldName
-fld类型
-fldContent
等
非常感谢
On a PHP/MySQL application...
We are planning to offer users the ability to create simple DataBases.
Let say it can get up to more than 10000 main user accounts and maybe several times more after some years.
What would be the efficient way to go?
A) Create the user defined tables and fields directly into our Application´s DB ?
Wouldn't that be like... our ~40 tables app´s AND like 10000 user created tables?
I understand that at the moment of querying and usage etc it will be efficient
B) Having tables of tables and fields?
like...
- table usrtables
- tabID
- usrID
tabName
etc.
table usrfields
-tabID
-fldName
-fldType
-fldContent
etc.
thank you very much
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您想成为托管数据库提供商，一个好主意是为每个用户提供自己的包含其表的数据库，这对于安全性和可扩展性来说是最好的。
选项 1 在单个数据库中运行所有用户将导致一些问题，因为您将有很多表，但至少您仍然能够扩展，因为只要每个用户的表不互相“对话”（ joins），您可以按用户将其分片/分区到多个主机。您最终得到的结构和工作量与最初为每个人提供自己的数据库几乎相同。如果您必须偶尔跨用户进行联接，那么这可能是更好的方法。
选项 2 将导致所有用户数据混合到巨大的表中，这很快就会开始导致索引写入开销、水平分区和锁争用等问题。实现可扩展性的方法是尽可能将数据分解为小的孤立块，这种方法正走向完全相反的方向。
If you want to be a hosted database provider a good idea is to actually give each user their own databases containing their tables, this will be the best for security and scalability.
Option 1 running all the user in your single database will result in some issues because you will have a lot of tables, but at least you will still be able to scale because as long as each user's tables are not "talking" to each other (joins), you can shard/partition by user to multiple hosts. You end up with almost the same structure and amount of work as giving everyone their own database in the first place. If you have to do joins across user once in a while this might be a better way.
Option 2 will cause all users data to mingle togather into huge tables, this will start to cause issue very soon with index write overheads, horizontal partitioning, and lock contention. The way to scalability is to try to break down data to small isolated chunks where possible, this approach is heading to the exact opposite direction.