删除“好友”的最佳做法是什么?来自数据库?
假设您有一个如下所示的表架构:friends(friendship_id, uid1, uid2, are_friends)
。
当一个朋友与另一个人取消好友关系时,最佳做法是从数据库中删除该行(并重置自动增量)吗?或者您应该简单地将 are_friends 状态更改为“N”?
我很想知道你的想法以及原因。
编辑:我主要关心的是显示有关好友状态的一些信息,以及显示谁加了谁的好友。这样,在添加时,我可以将好友的请求通知好友,但还没有让他们成为好友。
我最初将 are_friends
作为一个带有更多选项的大型 ENUM
。但在那个ENUM
中,我有removed
和blocked
等选项,我不确定这是否是真正有用的数据。关于拥有更多数据与更少数据的优点还有什么进一步的想法吗?
另外,自从我发帖以来,我一直有一个额外的问题,那就是如何避免重复友谊。您应该将 (uid1, uid2)
设置为主键吗?
Say you have a table schema such as this: friends(friendship_id, uid1, uid2, are_friends)
.
When one friend un-friends another person, is it best practice to delete that row from the database (and reset auto-incrementing)? Or should you simply change the are_friends status to 'N'?
I'd love to know what you think and why.
EDIT: My primary concern is showing some information about the state of the friends, and also showing who friended who. That way at the time of the add I can notify the friended of the friender's request and yet not have them be friends yet.
I had originally had are_friends
as a large ENUM
with more options. But in that ENUM
I had options such as removed
and blocked
, and I wasn't sure whether that was truly useful data or not. Any further thoughts on the merits of having more vs. less data?
Also, an added question I've had since I posted is how one should avoid duplicating friendships. Should you make (uid1, uid2)
a primary key?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
如果用户与其他用户重新成为好友,您是否希望恢复与
好友
记录相关的任何数据?如果您想跟踪他们的历史记录,或保留一些与他们的关系相关的元数据,请保留记录。
如果您不想跟踪他们的历史记录,并且稍后重新添加好友不需要用户输入任何额外数据,请将其删除。您将拥有更小的表、更容易的查询,并且您忘记 where 子句并向用户显示他们已删除的好友的可能性也会降低。
Is there any data associated with the
friend
record you might want to restore, if the user re-friends the other user?If you want to track their history, or keep some metadata associated with their relationship, then keep the record.
If you don't want to track their history, and re-friending later doesn't require user to input any extra data, delete it. You'll have smaller tables, easier queries, and decreased likelihood you'll ever forget that where-clause and show the user friends they've already deleted.
典型的 N:M 关系:
关系表中不需要
friendship_id
和are_friends
字段。这样,如果表中的关系存在,则用户是朋友,否则不是。
存储“不是朋友”的信息是无用的杂乱。
除非 @fencliff 描述的情况
,无论你做什么:永远不要重置自动增量,除非你重置整个数据库。
typical N:M relationship:
You dont need
friendship_id
andare_friends
fields in the relationship table.This way if the relationship in the table is present then users are friends, otherwise not.
Storing the "not friends" is a useless clutter.
Unless the case described by @fencliff
And whatever you do: never reset the auto-increment unless you reset the whole database.
我建议删除该行,因为首先,这是不必要的数据占用空间,而且下次用户决定与同一朋友重新成为好友时,如果需要,我们可以再次输入数据。
I would suggest to remove the row, because first thing is first, it is unnecessary data to occupy space, and besides the next time the user decides to re-friend with the same friend, then we can enter the data again, if needed.
我想说删除它。用于确认默认状态的不必要的数据实际上没有多大意义,尤其是即使是小型站点也可能会产生大量数据。如果您要在其中额外存储有用的数据,也许只需更改即可,但否则没有什么意义不这样做。
I'd say delete it. Unnecessary data to confirm what will be the default state doesn't really serve much point, especially with the amount of these even a smallish site would likely accrue. If you're going to store useful data extra in there, maybe just change, but otherwise there's little point not to.
我想说这首先取决于您的业务需求。如果您需要跟踪这两个人曾经是朋友并且不再是朋友的事实,那么您必须将该行保留在您的数据库中,可能还添加一些您可能感兴趣的更多列(当他们成为朋友时,当他们不再是朋友时,等等)。否则,您实际上并不需要此行,因此最好将其删除。当然,在这种情况下,您也不需要 are_friends 列,因为数据库中存在的所有行都将对应于朋友。
I'd say that this depends first of all on your business needs. If you need to keep trace of the fact that these two people where friends once and are not any more then you would have to keep the row in your db, possibly also adding some more columns you might be interested in (when they became friends, when they stopped being friends, etc.). Otherwise, you don't really need this row so it's better to delete it. Of course in that case you also don't need the are_friends column since all the rows existing in your db will correspond to people being friends.