2011-07-18 40 views
4

我正在重建具有大量流量的网站的后台系统。我应该如何为这个问题设计数据库结构?

这是应用程序的核心,我构建这部分数据库的方式对于大量代码和即将开展的工作至关重要。下面描述的系统每天需要运行数百万次。我很感谢在这个问题上的任何投入。

背景是用户可以添加他或她在白天吃的东西。

简化,该过程或多或少是这样的:

  1. 用户到达该网站,该网站列出了他/她的选择为天(如果进入之前下面介绍的步骤)。
  2. 用户可以添加一顿饭(由1组成的无限量的不同食物及其数量)。餐点通过搜索字段添加,并按不同类型组织(如“早餐”,“午餐”)。
  3. 在膳食建设过程中,会显示最常用的食品列表(主要由该用户,其次为所有用户),以便快速选择。
  4. 膳食将存储在一个FoodLog表中,其中包含如下内容:id, user_id, date, type, food_data

我目前拥有的是一个庞大的数据库与食品项目进行搜索。食物项目储存有关于常用名称(如“猪排”)和生产者(如“可口可乐”)的信息以及所需的其他详细信息。

问题总结:

我的问题是,我不知道存储数据的最佳方式为它在我需要的方式,并没有数据库走出去的手方便。

考虑一百万用户每天增加1至7餐。为了存储每餐中的每个食物,每天和每个用户每天可能创建(1 * avg_num_meals * avg_num_food_items)百万行。

以某种压缩方式存储数据(如food_data是一个json_encoded字符串),会显着减少行数量,但同时使其难以创建“最常用的食品”列表和其他即时统计。

该表应该分成几个表吗?如果是这样,他们将如何互动?

该网站目前托管在中档CDN上,并且使用LAMP(Linux,Apache,MySQL,PHP)骨干网。

+2

您已经想到了经典的数据库设计师的困境:规范化或不规范化。 –

+0

我正在阅读它:) – Mattis

+1

你是不是指VPS而不是CDN。你可以安装软件吗?如果你能,我会建议你使用例如Redis或memcached来研究缓存(使FAST成为地狱)。此外,我会建议您查看APC编译的PHP脚本的字节码。 – Alfred

回答

10

粗略地说,你需要一个完全标准化的数据结构。你想有一个用户表,一个Meals表(每餐一餐,参考用户;你可能还想在这个表中有一个时间/日期)和一个MealItems表,简单地说就是Meal和Food Items表中的关联表。

因此,当用户进来并创建一个帐户时,您在用户表中输入一个条目。当用户报告他们吃过的餐食时,您会在膳食表中创建一条记录,并在MealItems表中为他们报告的每个条目创建一条记录。

这种结构使得每餐都有可变数量的物品,而不浪费大量空间。您可以使用相对简单的查询来确定正餐中物品的表示形式,以及确定任何一个用户在任何给定时间段内消费的全部物品集合。

这个规范化的表结构将支持大量的记录并支持大量的数据库查询。

+0

通过4NF阅读正常化和了解1NF的信息我意识到,我可能会反对在多个表上使用JOIN。我试着尽量避免它,但对我来说这是越来越明显,这是需要和良好的做法。很好的答案! – Mattis

+0

@Mattis:很高兴帮助。是的,JOIN绝对是你的朋友。一旦你对他们感到满意,你会惊讶于他们是多么有用,他们表现如何。 –

1

我会把你的餐桌分成两张桌子,一张桌子为每顿饭储存一行,第二张桌子为每餐中使用的每种食物储存一行,用于英寸

之后,只要确保您在连接或WHERE子句中使用的任何表列的索引。

2

除了什么是been said

  • 在你使用索引的明智。正确地将这些应用于您的数据库可以显着加速对表格的读取访问。
  • 考虑使用特定于语言的功能来最小化空间。你提到你使用的是mysql;在适当的时候考虑使用ENUM(食物类型,膳食类型)以最小化数据库大小并简化管理。
+0

感谢您的ENUM指针:) – Mattis

3

首先,

存储在某种压缩方式的数据(如food_data是 json_encoded字符串)

是不推荐的想法。随着新的要求的增加,这将会导致你在将来无数的头痛。

你应该在这里肯定有几张表。

Users 
id, etc 

Food Items 
id, name, description, etc 

Meals 
id, user_id, category, etc 

Meal Items 
id, food_item_id, meal_id 

膳食项目将使用ID将膳食与食品项目联系起来。 Meals将与使用ID的用户绑定。这使得使用连接变得非常简单,以便获得数据汇总,平均值等的详细列表。如果这些字段被正确编制索引,这应该是支持大量记录的很好的模型。

+0

哈哈“可怕的”很好,我不会在重要的观点时狠狠地说话。感谢您的发布,我意识到我需要对我的数据库设计进行相当多的改造。 – Mattis