用于高效存储和检索的数据库结构
我有一个数据库，用于接收与特定足球俱乐部相关的链接和内容，我目前存储内容的方式是在 2 个单独的表中，1 个存储链接和详细信息，fm_sources，另一个存储俱乐部特定信息,fm_club，将用于对 fm_sources 内容运行查询以查找相关信息。
问题是，在一个 API 中，实际上可以保证与 1 个俱乐部关联的数据，对我来说，为每个俱乐部拥有一个不同的表，并将行与初始存储中的俱乐部关联，这对我来说会更好吗？使用非常简单的 SQL 查询，而不是像我使用的那样进行大量的 LIKE 比较 此处。然后我可以简单地运行这样的查询。
SELECT * FROM fm_liverpool ORDER BY created_date DESC LIMIT 15
然后，该方法将要求我为每个俱乐部拥有多个表，但每个表将复制相同的列。
Ive got a database that receives links and content related to a specific football club,and the way im storing the content at the moment is in 2 seperate tables,1 that stores the links and the details,fm_sources, and another that stores club specific information,fm_club, that will be used to run queries against the fm_sources content to find relevant infomation.
The question is,ive across an API that will virtually guarantee data that is associated with 1 club,would it be better for me to have a different table for each club with the rows being associated with the club on initial storage,this would allow me to use very simple SQL queries as opposed to massive LIKE comparisons as i used here. I could then simpley run a query like this
SELECT * FROM fm_liverpool ORDER BY created_date DESC LIMIT 15
This method would then require me to have multiple tables for each club but each table would replicate the same columns.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
规范化注释是正确的：您将有一个用于俱乐部名称和信息的表，一个用于 fm_sources 的表，可能还有一个链接这两个表的表。如果您获得更多数据，您将需要更多表格。
您实际上不必进行“大规模的类似比较” - 最多一次，为足球俱乐部查找名称。其他一切都应该由 ID 连接。
The normalization comment is correct: You would have one table for club names and information, one for fm_sources, and likely a third that links the two. You would need more tables should you get more data.
You shouldn't really have to do "massive LIKE comparisons" - at most one, for the football club look up name. Everything else should be JOINed by IDs.