设计用户内容网站（类似于yelp，但针对不同的市场和照片共享）并且几乎没有数据库问题：
每个用户都有自己的一套 表或我们存储多个 用户数据到公共表？以来 这甚至是社交网络的时候 用户规模增长以实现可扩展性 数据库通常是分区的 关闭。不同的用户组 单独发送，那么什么是最好的 进场？我想有些数据就像 用户帐户可以是共同的 桌子，但墙上的帖子，照片等 每个用户都会得到自己的表？ 如果是这样，那么如果我们有1000万 那么用户意味着1000万x 每个用户有多少个表？ 目前正在设计中 MySQL的
用户表如何知道什么 每次用户加入时创建 现场？我假设可能有一个 它的系统表模板 拉着田野？
除上述问题外， 如果明天我们修改表格， 添加/删除功能，滚动 更改为所有实时用户 帐户/表格 - 我从一个页面知道 我们拥有主人的观点 模板，但对于数据库，如何 用户表会更新吗？是 我们手动做的事情或者 表会像每一个一样继续检查 24小时与系统表 更新其结构？
如果以上都是真的，那意味着我们维护一组具有系统默认值的主表，然后每个用户都获得复制到其表中的相同值？某些字段，例如系统锁帐户之前的最大失败登录尝试次数。一个我们在30分钟内有系统默认的5次登录尝试。但是我想让用户也指定自己的号码来自定义他们赢得的安全性，这意味着他们可以在自己的表中覆盖系统默认值？
感谢。
答案 0 :(得分：1)
答案 1 :(得分：1)
通常，为每个实体（在这种情况下是用户）创建单独的表的想法不是一个好主意。如果每个表都是单独的查询可能很麻烦。
如果您的表很大，您应该使用索引优化表。如果它变得非常大，您也可能想要查看分区表。
这允许您将表视为1个对象，尽管它在逻辑上是分开的 - DBMS处理大部分工作并向您显示1个对象。这样就可以正常地选择SELECT，INSERT，UPDATE，ALTER等，并且DB会确定SQL引用的分区并执行命令。
用户不分割表，而是使用索引和分区，在保持性能的同时处理可伸缩性。如果你不手动拆分表，这也会使得第2,3和4点无法实现。
这是分区表的链接（特定于SQL Server）： http://databases.about.com/od/sqlserver/a/partitioning.htm
答案 2 :(得分：0)
为每个用户创建一组表对我来说没有任何意义。如果您为所有用户提供了一组通用表，那么我认为这可以避免您提出的所有问题。
答案 3 :(得分：0)
听起来你需要找到关系数据库设计基础的入门知识。无论您正在设计的应用程序类型如何，您都应该从那里开始。了解联接的工作方式，索引，主键和外键等。了解基本数据库规范化。
在应用程序中即时创建新表并不习惯;在正确设计的架构中通常是不必要的。通常，架构更改在部署时完成。 “用户”获得自己的表的唯一时间是供应决策的工件，其中每个“用户”实际上是围墙花园中的租户;只有每个“用户”（更有可能是公司或组织）永远不需要访问系统中其他用户存储的任何内容时，这才有意义。
有一些机制可以处理数据库中松散结构化的信息类型，但如果你发现自己经常达到这个目的（最常见的方法称为实体 - 属性 - 值），你的问题要么没有完全正确建模，要么您实际上可能不需要关系数据库，在这种情况下，使用像CouchDB / MongoDB这样的面向文档的数据库可能会更好。
根据您更新的评论/备注添加：
您对特定表中记录数量的担忧很可能为时过早。先得到一些工作。大多数现代DBMS，包括较新版本的MySql，支持索引和聚簇索引之外的机制，可以帮助处理大量记录。也就是说，在MS Sql Server中，您可以在表的字段上创建分区函数; MySql 5.1+有一些基于散列函数，范围或其他机制的类似分区选项。遵循完善的数据库设计惯例，尽可能合理地建模您的域，然后在遇到问题时进行调整。首先使用您选择的数据库中的可用工具进行调整，然后只有在您能够证明需要时才考虑更严格的措施。还有其他类型的非规范化更有可能在你甚至想要考虑像数据库系统那样对每个用户的“每个用户的表”模型做一些事情之前有意义。即使我要看那条路线，我也可能会首先考虑物化视图。
答案 4 :(得分：0)
我同意上面的评论，即每个用户的表格是一个坏主意。此外，虽然现在考虑到当事情变得非常重要时如何应对策略是个好主意，但我会集中精力为少数用户做好准备 - 如果没有人想要的话能够使用您的服务，但遗憾的是您不会遇到很多用户的问题。
非常大的网站中常见的方法是database sharding。摘要是：您并行（在不同的计算机上）有数据库的N个实例，每个实例保存总数据的1 / N.有一些共享方式可以知道哪个实例拥有一定数量的数据。要访问某些数据，您需要两个步骤，而不是您可能期望的步骤：
这有问题，例如：您设置了例如8个分片，它们都填满了，所以你想要共享数据，例如20个碎片 - ＆gt;在分片之间迁移数据。