社交Web应用程序数据库设计:如何改进此架构？
Arj*_*jun 11 mysql database schema database-design social-networking
背景
我正在为诗人和作家开发一个社交网络应用程序,允许他们分享他们的诗歌,收集反馈,并与其他诗人交流.我在数据库设计方面的培训很少,但我一直在阅读书籍,SO和在线数据库设计资源,以确保性能和可扩展性而不会过度设计.
数据库是MySQL,应用程序是用PHP编写的.我不确定我们是否会在应用程序中使用ORM库或从头开始编写SQL查询.除了Web应用程序之外,Solr搜索服务器和某些消息传递客户端将与数据库进行交互.
目前的需求
我在下面拼凑的模式代表了网站第一版的主要组件.最初,用户可以注册该站点并执行以下任何操作:
- 创建和修改配置文件详细信息和帐户设置
- 发布,标记和分类他们的写作
- 阅读,评论和"最喜欢"其他用户的帖子
- "关注"其他用户以获取其活动的通知
- 搜索和浏览内容并获取建议的帖子/用户(尽管我们将使用Solr搜索服务器索引数据库数据并运行这些类型的查询)
架构
以下是我在MySQL Workbench上为初始站点提出的建议.我对某些关系数据库事物仍然有点模糊,所以请轻松一点.
问题
- 一般来说,有什么我做错了或可以改进吗？
- 我有什么理由不将ExternalAccounts表合并到UserProfiles表中吗？
- 我有什么理由不将PostStats表合并到Posts表中吗？
- 我是否应该扩展设计以包含我们在第二个版本中执行的功能,以确保初始架构可以支持它？
- 有什么办法可以优化Solr索引/性能/数据库的DB设计吗？
- 我应该使用更自然的主键,例如Username而不是UserID,还是zip/area代码而不是Locations表中的代理LocationID？
谢谢您的帮助!
总的来说，我有什么做错的地方或者可以改进的地方吗？
总的来说，我没有发现您当前的设置或架构有任何大缺陷。
我想知道的是你分成了 3 个 User* 表。我明白你想要什么你的意图是（将不同的用户相关的东西分开），但我不知道我是否会选择完全相同的东西。如果您打算仅显示User网站上表格中的数据，这很好，因为在同一页面上不需要多次使用其他信息，但如果用户需要使用他们的真实姓名并显示他们的真实姓名（例如 John Doe） doe55），当数据变大时，这会减慢速度，因为您可能需要连接。拥有Preferences单独的似乎是个人选择。我没有赞成或反对的理由。
您的多对多表不需要额外的 PK（例如PostFavoriteID）。两者的组合初级PostID就UserID足够了，因为PostFavoriteID从未在其他地方使用过。这适用于所有连接表
我是否有任何理由不应该将ExternalAccounts 表合并到UserProfiles 表中？
与上一个一样。回答，我没有看到优点或缺点。我可以将两者放在同一个表中，因为NULL（或可能更好-1）值不会打扰我。
我是否有任何理由不应该将 PostStats 表合并到 Posts 表中？
ViewCount我将使用触发器将它们放入同一个表中来处理表的增量
我是否应该扩展设计以包含我们在第二个版本中所做的功能，只是为了确保初始架构可以支持它？
您使用的是normalsied 模式，因此可以随时进行任何添加。
我可以做些什么来优化 Solr 索引/性能/其他方面的数据库设计吗？
不能告诉你，还没有做过，但我知道 Solr 非常强大和灵活，所以我认为你应该做得很好。
我是否应该使用更自然的主键，例如用户名而不是用户 ID，或者邮政编码/区号而不是位置表中的代理位置 ID？
SO 上有很多线程讨论这个问题。就我个人而言，我更喜欢代理键（或另一个唯一的数字键，如果可用），因为它使查询更容易、更快，因为 int 更容易查找。如果您允许更改用户名/电子邮件/无论您的 PK 是什么，则需要进行大量更新。有了代理键，您就不需要费心了。
我还要做的就是添加诸如created_at, last_accessedat （最好通过触发器或程序 IMO 完成）之类的内容，以获得一些可用的统计数据。这确实可以为您提供有价值的统计数据
提高性能的进一步策略包括内存缓存、计数器缓存、分区表……当您确实被用户淹没时可以讨论这些事情，因为可能有一些非常具体的东西/技术/技术/...对你的问题。