表中的列经常为 NULL 是不是很糟糕？
表中的列NULL经常为空是否不好？
评论表
comment_id member_id user_id
1 1 NULL
2 1 NULL
3 1 NULL
4 1 NULL
5 1 NULL
6 1 NULL
7 NULL 1
8 NULL 1
9 NULL 1
10 1 NULL
Is it bad to have a column empty as NULL often in a table?
comment table
comment_id member_id user_id
1 1 NULL
2 1 NULL
3 1 NULL
4 1 NULL
5 1 NULL
6 1 NULL
7 NULL 1
8 NULL 1
9 NULL 1
10 1 NULL
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不，这并不是“坏”，尽管一些顽固的规范化狂热分子坚持认为允许
null违反了关系数据库法律。如果你的桌子上有很多这样的东西，你可能想看一下设计是否合适，但在没有更多背景的情况下，你不能说它在每种情况下都是不好的。
No, it's not 'bad' although some die-hard Normalization fanatics will insist that allowing
nulls violates relational database laws.If you have a table with a lot of them, you might want to take a look and see if the design is appropriate but you can't say it's bad in every case without more context.
不，这本质上并不是坏事。
NULL条目是一个工具，您可以根据需要使用该工具。现在，在您发布的情况下，您可能会考虑使用不重叠的用户和成员 ID 并使用一列来存储其中之一，但这是您的决定。
No, it's not inherently bad. A
NULLentry is a tool, and you may use that tool as you like.Now, in the case you posted, you might consider having non-overlapping user and member IDs and using one column to store either, but that's your decision.
它可能不会造成太大的性能问题。看起来您的表中的成员和用户之间有某种区别。假设没有人可以是成员和用户，您可以有一列用于成员/用户 ID，但随后您需要另一列来标识他们是用户还是成员。这实际上需要比您现在拥有的解决方案更多的存储空间，所以我认为您没问题。
It's probably not causing much of a performance issue. It looks like you have some sort of distinction between members and users in your table. Assuming nobody can be a member AND a user, you could have one column for member/user id but then you would need another column to identify whether they were a user or a member. That would actually require MORE storage than the solution you have now so I think you're fine.