我有两张桌子（例如）：
用户（ID，firstName，middleName，lastName）
联系人（ID，userID，serialNo，phoneNumber，eMail）。
我将通过phoneNumber或eMail或两者与用户进行通信（发送消息）并将其保存在数据库中（例如）。
记录（ID，用户ID，联系ID，消息，onPhoneOrEmail），例如，最后一个字段存储，例如，＆＃39; p＆＃39;＆＃39; e＆＃39;或者＆＃39; b＆＃39;，用于phoneNumber，eMail或两者。
所以，当我检查日志时，我可以知道哪条消息被发送到哪个电子邮件/电话号码。
问题：
用户更改其联系详细信息时该怎么办？
如果我更新“联系人”表，则会丢失“日志”，因为邮件未发送到新号码。
如果我将数字或电子邮件存储在日志中，那么将存储大量数据（与一个字符相比大规模存储）。
最后：如果我添加+1序列号（serialNo - field）的新联系人，它是否可行？性能问题怎么样？ （不需要唯一性，用户可以根据需要随时更改号码或电子邮件 - 这些仅用于通信）。
我看过this和this，但无法就性能/方法问题得到合适的答案。
请指导。
示例数据：
USERS
| 1 |约翰| null | Cena |
CONTACTS
| 1 | 1 | 1 | 123456 | abc@xyz.com
| 2 | 1 | 2 | null | xyz@mnp.com
| 3 | 1 | 3 | 987654 | 空
答案 0 :(得分：1)
如果您说用户可以更改其联系人详细信息，则意味着您将依赖关系置换。用户具有联系人，因此将用户与contactID相关联而不是相反的用户是合理的。现在，用户可以更改，例如随时随地打电话，同时在同一时间更改用户的同一电话号码毫无意义。
所以它会像这样：
用户（ID，firstName，middleName，lastName，contactID）
联络（ID，serialNo，phoneNumber，电子邮件）
记录（ID，用户ID，消息，onPhoneOrEmail）。
您不需要Log上的userID和contactID。请记住，一个是另一个的外键（传递依赖）。
修改 如果您需要为每个用户存储多个联系人，请保留您的架构，但更改登录
记录（ID，contactID，消息，onPhoneOrEmail）
从我的角度来看，当您需要更改用户的联系时，这意味着您将删除一个并添加另一个。如果您从未向正在删除的联系人发送任何消息，则您没有理由将其保留在内存中，否则，如果您需要记录，则必须在更换后将内容中的联系信息保留在内存中（可能是一列说它无效是可取的）。这已经是mySQL中的默认行为（ON DELETE RESTRICT）。
答案 1 :(得分：1)
摆脱您的联系表。
创建一个新的UserPhone表（PK - ID，FK - User.Id，Phone＃，ActiveDate）
创建一个新的UserEmail表（PK - ID，FK - User.Id，Email， ActiveDate）。
看起来SerialNumber只是一个增量器 一个用户的联系人数据。如果它只是一个增量器，ActiveDate 应该足以替代。
手机时，电子邮件信息更改不会更新现有记录，而是添加今天日期的新记录。
您的日志表格如下（PK - LogID，FK - UserEmail.ID，FK - UserPhone.ID）。
不需要PhoneOrEmail字段。该信息可以通过FK的存在来确定。
您可能还有其他一些设计问题，但这个答案可以让您走上正确的道路。