我有一个父表，其中包含 demographics 以及 consent 数据。
父表如下所示
Person_id, Age, gender, Name, DOB, Consent_agreed, Agreed_share_phone_number, agreed_share_email
1 21 M FM , 10/1/90 N N N
2 23 F MF , 11/1/92 Y Y Y我计划像下面这样存储数据
DEMO Table
Person_id, Age, gender, Name, DOB
111 21 M FM , 10/1/90
222 23 F MF , 11/1/92
CONSENT Table
Consent_Id Person_id Consent_agreed Phone_number email
1 111 N N N
2 222 Y Y Y我为同意创建了一个单独的表，因为一个人可能会随着时间的推移更新他的同意，并且可能有多个记录。
我这样正常化对吗？
我该如何决定是否提供 consent_id 在 DEMO table 不管怎样。
演示表列是否如下所示 consent_id 表示最新同意状态或同意状态不应包含在演示表中
Person_id, Age, gender, Name, DOB, consent_id
4条答案
按热度按时间4nkexdtk1#
“一个人可能会随着时间的推移更新他的同意，并且可能有多个记录。”一个人的多个同意行无疑是按您的方式拆分表的一个原因。
如果有效同意书始终是
consent对一个人来说(demographics行）没有理由存储consent_id在demographics.af7jpaap2#
我想；
演示表已正确设计，不应再次编辑。但是同意表的设计，与你的使用有关，可能会改变。如果要查看所有同意数据，则所有数据都可以位于表中。除非要查看所有同意数据，否则可以将最新数据保存在同意表中。旧的同意数据可以保存在同意历史表中。这样，您可以更快速地访问最新的数据。
omqzjyyz3#
我建议加上这个
current_consent字段到演示表。虽然这看起来像是一个数据和逻辑的双重应用程序（您必须确保
current_consent指最新的同意），但它会简化你以后的生活很多。试想一下，每次检查当前许可时，您都必须编写sql查询（而且这比查看历史记录的次数要多得多）。还有性能方面的考虑。您将没有简单的联接-您必须使用join-leteral或subquery。如果你或你团队中的某个人忘记了这一点，而使用简单的连接，那么性能将受到影响。我不是说
current_consent会解决你所有的问题（实际上会带来更多的问题，因为这样你就可以选择如何查询你的同意书，确保最新的同意书总是最新的……），但它会使你的查询更短更快。你总是把你的问题和你没有的问题交换我猜…：）iswrvxsc4#
上面提供的答案是绝对正确的。但如果我是开发商，我会提出如下问题：
正如您所提到的，随着时间的推移，可能会有很多同意，记录它的timestamp列在哪里？我建议你加上那一栏。
您是否必须始终显示最新的同意状态？如果是的话，您认为在person表中具有最新的同意状态是好的。如果没有，我建议你有一个观点，既人和同意，并显示最新的同意，只要需要。这样，您将保存更少的数据，这意味着同意状态没有冗余。
希望我给了你一个正确的答案。
你好，柴坦亚