用户信息的推荐数据库结构

我想弄清楚我应该如何在我的网站上为用户信息构建数据库结构（表格）。的信息，我会被存储（此时反正）的种类有：用户信息的推荐数据库结构

关于我
生日（一月，1，1970年）
性别（男/女）
感兴趣的方面（男，女，两个）
婚姻状况：（单，在一个关系，订婚，结婚）
网站：（mywebsite.com）
来源：（加州Cupertino）

所以这是我现在要存储的信息的类型。我的问题基本上是，我应该只有一张桌子吗？或者根据它是什么来分割信息会更好（我的用户有一个独特的ID，这显然会与每个信息表一起出现）。所以我不确定我是否应该专门为生日提供列：userID，Month，Day，Year;或者是什么。

来源

2012-11-06 Dylan Cross

如果用户只需要存储属性的一条信息，那么您不需要单独的表。例如，用户只有一个生日。如果您想为同一用户名存储多个生日，您需要单独的Birthdays表的唯一原因是。列出的每个属性看起来好像在一个Users表中都可以。

至于将Birthdays分成列：userID，Month，Day，Year，这一切都取决于你将如何使用该信息。您是否需要知道只是用户生日的月份，日期或年份？如果这是一种常见的需求，您可能需要单独存储它们。通常不会，所以您可能只想将它作为单个Date值存储。

注意：您可以通过检查Data Explorer来查看Stack Overflow使用的模式。他们在一个Users表中保留了一个类似的数据集合。

来源

2012-11-06 00:22:34

我会避免把生日分成几部分，因为如果你只是想要“约会”，这是一个非常具体的反规范化和屁股疼痛。拆分*仅*如果存在证明*（证据确凿）的性能问题，可以通过这种方式解决，并且重要的是*需要*寻址。这将是“早期优化”以开始使用分割日期设计的经典错误。 – Bohemian

谢谢你的回答。以前，我只用了一张表来处理所有这类信息，而且我一直打算到现在为止继续这样做，但是我正处于为发布日期而开发我的网站的最后阶段，而且我正试图想出在未来允许数据灵活性的最佳方式。比如对于生日专栏部分，截至目前，我不知道我将如何使用这些信息，但我希望以尽可能最好的方式存储它，以便我可以以任何方式使用它未来。 –

@Bohemian我坚持这个例子，因为它是OP使用的那个。一个更好的例子可能是一个地址。有时候你需要在不同的领域中使用城市，州，邮编等，但有时地址只能被当作原子数据。这真的取决于它将如何使用。 –

在绝大多数情况下，我已经看到了你要求存储在一张表中 - 通常是user或users。

也许包括若干其它元件也：

用户ID（唯一的）

登记日期

状态（活/过期/禁止）

用户散列

加上各种其他...

老实说 - 这取决于你在建什么和如何建造，但我的建议是从简单开始。

关于你提到的生日点，只是存储在MySQL日期格式：

YYYY-MM-DD

这样的话，你可以操纵它的各种使用MySQL的函数的方式。

希望这会有所帮助。

来源

2012-11-06 00:23:38 nickhar

谢谢你，请看看我对比尔蜥蜴的回答的评论，它也可以直接应用于你的答案。 –

@DylanCross的确。我已经知道一个单用户表用于数百万用户，所以它不会像它不会缩放... – nickhar

嗯，这是更多的信息被存储，所以我可以以不同的方式使用它，我甚至可能打算现在使用它，我以前做过的方式并不总是让我做到这一点（或者非常容易） –

用户信息的推荐数据库结构

回答

相关问题