2012-01-11 46 views
2

我需要专业的程序员/ DBA来反驳我的想法,并知道它是否可以工作。请阅读以下内容,并提供任何可能破坏这一理论的信息。谢谢。需要的设计意见:为用户提供的模板数据库/表格


概述网站的想法:
该网站将通过体育卡收藏家可以用来聊天,回答在论坛上提问,展示自己的卡/盒休息,交易/出售/与其他用户,并保留他们的卡片的集合。

设计问题:
用户可以拥有的卡片数量不限。这可能会造成一些非常大的表格。

设计问题:
我不想限制有多少卡可以把自己收集的网站上有用户。如果他们有一张卡的5份副本,并且宁愿有5张记录,每张卡一张,那么这是他们的特权。这可能也是必要的,因为每张卡可能处于不同的状态。但是,通过允许这种情况发生,这意味着只有一个表格来存储所有用户的所有记录甚至不会接近选项。我知道拥有超过1,000,000张卡片的体育卡片收藏家。

我在想,通过为每个用户创建一个表或数据库,它将允许更快的查询。所有的数据库都在同一台服务器上(我不知道我的主机是谁,只在当前的设计阶段)。将会有一个主数据库,其中包含每个人都需要的数据(基本项目,而用户表/数据库将具有对基本项目的引用)。我确实发现某个字段可能是另一个数据库的外键,所以我知道我在这方面的想法是可能的,但总体而言,我不确定最好的想法是什么。

我看到大多数主机说“无限数量的数据库”这是让我想到每个用户的数据库。我可以将此用于线程上的用户帖子,收集项目,他们的首选项和其他信息。而且,通过让每个用户拥有不同的表格/数据库,如果某人的表格因任何原因需要重新编制索引,则不会影响其他用户。

但是,我最担心的是任何一种方式都会增加/删除表/数据库的结构。我非常确定可以编写一个脚本来进行必要的更改,但这似乎是一个相当高的风险。例如,我非常确定我可以编写一个脚本来为每个数据库或所有类似的表中的特定表添加一个字段,但是然后验证它们可能会很困难。


任何想法,你可以扔在那里为我将不胜感激。我一直在尝试在这个网站上工作一年多,并且一直在数据库设计上陷入困境,因为我担心表格太大,响应时间慢,并且如果用户数量增长,则会突破一些由phpMyAdmin的/ MySQL的。我也不想在数据库建设的一半,然后认为有一个更好的方法来做到这一点。我知道可能有多种方式来做到这一点,但最常见的做法是什么?非常感谢你。

+0

“这可能会使一些非常大的桌子”。比“拥有超过1,000,000张卡的收藏家”更加谨慎地定义非常大的?这有多少收藏家?他们将如何输入所有这些数据? – 2012-01-11 20:25:47

+0

我仍然在努力,因为“从文件上传”会很困难。我试图避免用户创建他们自己的卡片描述,因为它使得一些用户难以在寻找交易时找到他们想要的东西。但没有多少人拥有超过1,000,000张卡片,平均而言,我认为每个用户平均约有25,000张卡片。但我目前使用的网站拥有超过100,000个用户,因此您正在查看25亿条记录。我不确定这是一个表的可行数量的记录。如果它增长,谁知道。 – XstreamINsanity 2012-01-11 20:29:03

+0

而我试图阻止用户创建他们自己的卡片描述的原因是因为已经有相当不错的定义结构用于卡片描述。在大多数有数据库供您搜索的收集网站上,您必须查找您的卡,将其添加到您的收藏中,然后更新数量。我可能不得不与一些当前网站合作,在我们之间传输信息,但我认为我不希望用户上传文件,除非他们遵循了非常严格的说明。 – XstreamINsanity 2012-01-11 20:31:06

回答

2

我在想,通过为每个用户创建一个表或数据库,它将允许更快的查询。

这是错误的。单个数据库将会更快。

除非您拥有1,000,000个用户,否则每个用户1,000,000张卡片并不是一个真正的大数字。

多个数据库是管理的噩梦。单个数据库总是首选。


我太大的表,响应时间慢的烦恼,而且如果用户数量增长,突破一些制约因素通过phpmyadmin的设置/ MySQL的

你会捉襟见肘超过MySQL限制。

响应速度慢是您的应用程序的一部分,您的SQL查询的细节比其他任何事情都要多。

最后。最重要的。

所有技术都过时了。最终,你必须取代的东西。为了达到你不得不升级的地步,你必须先运行一些东西。

不要担心“大型数据库”,直到您拥有数十亿的行数。

不要担心“长期”解决方案,因为所有软件技术都会过期。很快。


关于用户数量。

大部分的网页互动是通过JavaScript与浏览器交互的时间。或阅读一个页面。点击实际上很少见。 MySQL在一个相当大的服务器上应该能够处理30个或更多的几乎同时发生的查询,并提供亚秒级响应您的应用程序可能需要很少的时间格式化并开始发送HTML页面。在一个典型的服务器上,一个非常非常好的剪辑可以让事情崩溃。

如果您的数据库设计避免了可怕的全表扫描。

您必须对最常见的查询有适当的索引。

现在。 30个几乎同时发生的请求的几率是多少?如果用户每10秒钟点击一次(他们必须阅读页面,填写表格,重新阅读页面,想想,喝他们的啤酒),那么一秒钟内30次点击的几率意味着您必须有300 并发用户。考虑到人们在他们的生活中还有其他事情要做,这意味着你必须有5万左右的用户(他们每周在你的网站上花费1个小时)。

+0

因此,访问表的用户数量以及该表中的行数是多少,这更多关于表本身是如何设计的? – XstreamINsanity 2012-01-11 20:37:09

+0

这些都是关于规范化,反规范化和索引。使用索引来查询少量行的查询使用索引树,并且运行于(几乎)恒定时间,与数据库的大小无关。无论表格有多小,没有扫描表的索引的查询都很慢。 – 2012-01-11 20:38:22

+0

非常感谢。我担心过多地获取某些东西,然后立即需要升级它,这就是为什么每当我设计一些东西时,我都会在出现问题之前查看下一个可能的解决方案。非常感激。 – XstreamINsanity 2012-01-11 20:40:40

1

我不会走上创造的道路每个用户都有一个数据库......这会为你造成无数的麻烦:数据完整性问题,参照完整性问题,管理问题......

只要你的表很好地标准化和索引,我不认为具有数亿行的表格非常大。

相反,我只是从一个简单的表格设计开始。如果您的网站非常成功,那么在MySql中实施partitioningsharding并不是什么额外的努力,而不是马上扩大规模。

1

如果我在你的鞋子里,我会从一个数据库和一张桌子开始,而不必太担心桌子可能的大小。如果您取得如此成功并达到规模,您可能会想出更多关于您的域名的资源和知识,以便做出更明智的决定。一旦发生这种情况,您还可以考虑使用noSql解决方案,例如HBaseMondgodb和其他允许水平扩展(无限大小)的解决方案,以及面临处理大数据的企业的一些限制。您也可以使用mysql partitions或其他分片解决方案。所以,建立你的产品与一张桌子,不要为这个问题出汗,直到你绝对需要。祝你好运!