database - 从两个列表中找到适合删除的数据结构

Question

这可能会被删除，因为涉及到想法共享，这在堆栈溢出中是不允许的，但在此之前，如果我能从可靠的程序员那里得到任何想法，这对我来说将是一个胜利的局面

假设您有一个类 Student，存储在数据库中，并且这个类有一个名为 favoriteTeachers 的列表属性。该列表会不断被系统更新，并涉及教师的 ID。

您还有一个类 Teacher，它也存储在数据库中，同样有一个列表属性 favouriteStudents。它再次不断更新，并涉及学生的 id。

在我们的系统中，当学生调用一个函数(比方说 notMyFavoriteTeacher)时，我们的系统必须应用以下更改；

1. 从 favouriteTeacher 列表中删除给定教师的 id
2. 从给定教师的 favouriteStudent 列表中删除学生的 id

我已经考虑过更新的行数可能会耗尽数据库，因此我没有将学生与他们最喜欢的老师映射到单独的表中作为 user_id, teacher_id，而是创建了一个列并存储了一个字符串，其中包含以逗号分隔的教师 ID。 (例如:“1,2,14,4,25”)。同样适用于老师。

但是当我们调用这个函数的时候，我们也面临着另外一个问题。为了完成此操作，您需要将字符串转换为列表，通过线性搜索找到元素，然后删除，然后将列表转换为字符串并推回数据库。您还必须为 teacher 类执行其他操作。如果我们不应用字符串方法，删除会更容易，但由于我们每天要处理大约 2k 次删除和添加操作，我认为这不可行 使用单独的表格。

我想问一下，为了减少操作次数，是否可以选择一种数据结构来提高效率？

Answer 1

将关系存储为单个列中的数组违反了 first normal form , 没有充分理由不应这样做。尽管在某些情况下，各种形式的非规范化可能会提高效率，但我不认为这种情况是其中之一。更糟糕的是，您在实现参照完整性方面不会从数据库获得任何帮助。并且一些操作将导致有保证的行扫描:删除教师时，您将必须检查每个学生的每一行以将教师从每个学生的收藏夹列表中删除。删除学生也是如此。

关系数据库的设计和构建是为了将行链接到其他行。你需要一个很好的理由来阻止他们做他们设计好的事情。你应该继续设计一个合适的关系模式，只有当实际测量表明它太慢时你才应该担心它的性能。