我应该为两个相似的对象制作两个单独的表吗
我想将“推文”和“Facebook 状态”作为“状态集合”的一部分存储在我的应用程序中，这样每个状态集合都会有一堆推文或一堆 Facebook 状态。对于 Facebook，我只对文本感兴趣，所以暂时不会存储视频/照片。
我想知道数据库设计的最佳实践。是使用一张表（将状态的最大值设置为 420 以包括 Facebook 和 Twitter 限制）和“类型”列来确定它的状态更好，还是使用两个单独的表更好？为什么？
I want to store "Tweets" and "Facebook Status" in my app as part of "Status collection" so every status collection will have a bunch of Tweets or a bunch of Facebook Statuses. For Facebook I'm only interested in text so I won't store videos/photos for now.
I was wondering in terms of best practice for DB design. Is it better to have one table (put the max for status to 420 to include both Facebook and Twitter limit) with "Type" column that determines what status it is or is it better to have two separate tables? and Why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
严格来说，推文与 FB 更新不是一回事。您现在可能会忽略非文本，但稍后您可能会改变主意并陷入无效的模型。作为一般规则，对象不应被视为可互换的，除非它们确实可以互换。如果它们只是相似，您应该使用 2 个单独的表或根据需要使用其他列。
话虽如此，如果它真的只是文本，那么您可能只需一张表就可以了。但这是一个见仁见智的问题，你可能会得到很多答案。
Strictly speaking, a tweet is not the same thing as a FB update. You may be ignoring non-text for now, but you may change your mind later and be stuck with a model that doesn't work. As a general rule, objects should not be treated as interchangeable unless they really are. If they are merely similar, you should either use 2 separate tables or use additional columns as necessary.
All that said, if it's really just text, you can probably get away with a single table. But this is a matter of opinion and you'll probably get lots of answers.
我会将消息放入一个表中，并使用另一个表来定义类型：
它们看起来足够相似，没有必要将它们分开。如果您想跨两个社交网站进行查询，它也会让您的生活更轻松。
I would put the messages into one table and have another that defines the type:
They seem similar enough that there is no point to separate them. It will also make your life easier if you want to query across both Social Networking sites.
它可能更容易在表格上使用并使用类型来识别它们。当您有多个表时，您只需要一个查询/存储过程来访问数据，而不是每种类型一个查询。
Its probably easier to use on table and use type to identify them. You will only need one query/stored procedure to access the data instead of one query for each type when you have multiple tables.