社交Web应用程序数据库设计：如何改进此架构？

Question

背景

我正在为诗人和作家开发一个社交网络应用程序，允许他们分享他们的诗歌，收集反馈，并与其他诗人交流。 我在数据库设计方面的培训很少，但我一直在阅读书籍，SO和在线数据库设计资源，以确保性能和可扩展性而不会过度设计。

数据库是MySQL，应用程序是用PHP编写的。 我不确定我们是否会在应用程序中使用ORM库或从头开始编写SQL查询。 除了Web应用程序之外，Solr搜索服务器和某些消息传递客户端将与数据库进行交互。

目前的需求

我在下面拼凑的模式代表了网站第一版的主要组件。 最初，用户可以注册该站点并执行以下任何操作：

• 创建和修改配置文件详细信息和帐户设置
• 发布，标记和分类他们的写作
• 阅读，评论和“最喜欢”其他用户的帖子
• “关注”其他用户以获取其活动的通知
• 搜索和浏览内容并获取建议的帖子/用户（尽管我们将使用Solr搜索服务器索引数据库数据并运行这些类型的查询）

架构

以下是我在MySQL Workbench上为初始站点提出的建议。 我对某些关系数据库事物仍然有点模糊，所以请轻松一点。

问题

1. 一般来说，有什么我做错了或可以改进吗？
2. 我有什么理由不将ExternalAccounts表合并到UserProfiles表中吗？
3. 我有什么理由不将PostStats表合并到Posts表中吗？
4. 我是否应该扩展设计以包含我们在第二个版本中所做的功能，以确保初始架构可以支持它？
5. 有什么办法可以优化Solr索引/性能/数据库的DB设计吗？
6. 我应该使用更自然的主键，例如Username而不是UserID，还是zip / area代码而不是Locations表中的代理LocationID？

谢谢您的帮助！

Answer 1

一般来说，有什么我做错了或可以改进吗？

总的来说，我没有看到您当前的设置或架构中存在任何重大缺陷。

我想知道的是你分成3个User *表。 我得到了你想要的东西（不同的用户相关的东西分开），但我不知道我是否会采用完全相同的东西。 如果您计划仅显示网站上User表中的数据，这很好，因为在同一页面上不需要多次其他信息，但如果用户需要使用他们的真实姓名并显示他们的真实姓名（如John Doe）而不是doe55）因为你可能需要连接，所以当数据变大时这会减慢速度。 将Preferences分开似乎是个人选择。 我没有赞成也不反对它。

您的多对多表不需要PostFavoriteID PK（例如PostFavoriteID ）。 PostID和UserID组合主要是足够的，因为PostFavoriteID从未在其他地方使用过。 这适用于所有连接表

我有什么理由不将ExternalAccounts表合并到UserProfiles表中吗？

与上一样。 回答，我没有看到一个优点或缺点。 我可以将两者放在同一个表中，因为NULL （或者更好的-1 ）值不会打扰我。

我有什么理由不将PostStats表合并到Posts表中吗？

我会使用触发器将它们放入同一个表中以处理ViewCount表的增量

我是否应该扩展设计以包含我们在第二个版本中所做的功能，以确保初始架构可以支持它？

您正在使用标准化架构，因此可以随时进行任何添加。

有什么办法可以优化Solr索引/性能/数据库的DB设计吗？

不能告诉你，还没有完成它但我知道Solr非常强大和灵活，所以我认为你应该做得很好。

我应该使用更自然的主键，例如Username而不是UserID，还是zip / area代码而不是Locations表中的代理LocationID？

这里有很多线索在讨论这个问题。 就个人而言，我更喜欢代理键（或其他唯一数字键，如果可用），因为它使查询更容易和更快，因为更容易查找int。 如果您允许更改用户名/电子邮件/无论您的PK是什么，那么需要进行大量更新。 使用代理键，您无需费心。

我还要做的是添加像created_at ， last_accessed （最好通过触发器或程序IMO）这样的东西来获得一些统计数据。 这可以真正为您提供有价值的统计数据

进一步增加性能的策略将是memcache，计数器缓存，分区表等......当你真的被用户占用时，可以讨论这些事情，因为可能存在非常具体的事物/技术/技术/ ......你的问题。

Answer 2

我不清楚你的User *表格发生了什么 - 它们的设置好像它们是1：1但是图表反映了1对多（乌鸦的符号）。

ExternalAccounts和UserSettings可以进一步规范化（在这种情况下它们将是1对多！），这将为您提供更易于维护的设计 - 您不需要为您的架构添加更多列以获得额外的外部帐户或通知类型（尽管在性能方面可能不太可扩展）。

例如：

ExternalAccounts
    UserId int,
    AccountType varchar(45),  
    AccountIdentifier varchar(45)

将允许您以相同的结构存储LinkedIn，Google等帐户。 同样，可以使用以下结构轻松添加更多通知类型：

UserSettings
    UserId int,  
    NotificationType varchar(45),  
    NotificationFlag ENUM('on','off')

心连心