高效的sql数据库设计

时间:2011-02-15 23:49:44

标签: sql mysql

我对mysql相对较新,并且想知道存储内容的最佳结构。不同的论坛似乎提出了不同的建议。

想象一下,我正在尝试创建自己的webmail服务,我会有一个用户表:

|userid|username|password|joindate|

如果我想将每个用户的电子邮件存储在一个表格中,我该怎么做?我找到的一个解决方案是拥有一个emails表并执行以下操作:

+------+--------------+---------------+
|userid|subject       |message        |
+------+--------------+---------------+
|1     |Hello         |some message   |
|1     |Another email |another message|
|2     |An email for 2|message        |
+------+--------------+---------------+

即。此表将包含属于每个用户的每封电子邮件。这看起来过于繁琐,这有一种优雅的方式吗?

5 个答案:

答案 0 :(得分:3)

  

我对mysql比较新,而且是   想知道最佳结构   存储东西。

定义“最佳”。

哪种数据库结构可能“最佳”严重依赖于上下文。

最适合什么?插入,选择?有什么选择标准,联接,订购等

  

这个表将包含每一个   属于每个用户的电子邮件。   这看起来过于繁琐了   这是一个优雅的方式吗?

你到底发现什么是繁琐的?这很简单。 ?

答案 1 :(得分:1)

这是优雅的方式。它允许你做这样的事情:

SELECT *
FROM email
WHERE email.userid = $userToSearchFor

答案 2 :(得分:1)

这是关系数据的理想选择,即相同的数据存储在一个表中。

然后该数据可以与其他数据有关系。

即在您的情况下,您的数据与用户(通过用户ID)有关系。您的所有用户都存储在一个表中,您的所有电子邮件都存储在一个表中。

您可能会有更复杂的关系,例如电子邮件是CC还是发送给多个人。然后,您可能需要另一个表来处理用户和电子邮件之间的映射。

您可能希望在电子邮件表格中显示日期和主要ID,以便与其他表格中的特定电子邮件建立关系。

答案 3 :(得分:0)

老实说,我认为这取决于您正在创建的服务。

使用电子邮件地址作为用户名是完全可以接受的,因为根据定义,它必须是唯一的。在这种情况下,我认为它绝对属于用户关系。

对于您的示例,每个用户存储多封电子邮件,您提供的解决方案应该可以正常运行。

答案 4 :(得分:0)

首先,优秀的问题。很高兴您正在思考和询问这一点,而不是提前收费,并制作一些在现实世界中迅速崩溃的东西。当然,如果这是你的第一个数据库,你可能会得到它,这就是学习通常的方式。我们都写了一些可怕的意大利面条代码,但是专业人士和业余爱好者之间的区别在于从痛苦中学习并投入精力,以便下次做出更好的解决方案。

你的问题没有一个简单的答案,其他人已经提出了重点。我想补充一点:拿一本关于规范化的简短书(我在O'Reilly的“Nutshell”系列中取得了不错的成绩)。这可能听起来像一个大话题,但要点很简单:任何特定的信息只存储一次。这样可以节省空间,但更重要的是意味着您不会在不同的表中存储不一致的用户名。

尝试考虑大局:不仅仅是你现在需要的,还有将来你可能需要的东西,比如Keith指出的CC领域。电子邮件可以包含多个目标,因此,To表中的CCEMails字段不是EMailDestinations,而是一个EMailID表,其中包含字段Destination {1}},DestinationTypeDestinationType。这已经是一个更具可扩展性的设计示例:使用此模型,您可以开始仅使用一个{{1}}来跟踪BCC。但是,如果你能确定电子邮件只有一个目的地,那么对你的项目来说可能是过度工程。重要的是要考虑所有的可能性,即使你最终得到的设计足以满足你的需求。

祝你好运!如果将来有问题,请随时回复SO。如果你有一个明确而具体的问题,你通常会很快得到答案。