合并不同表列的数据设计问题
我有 2 个表:会员表和邮件列表表。
[Members]
Username
Password
EmailAddress
MailingListOptIn [bit]
Planes [bit]
Boats [bit]
Cars [bit]
- 水果栏是用户的偏好。
邮件列表用户
[MailingList]
EmailAddress
MailingListOptIn
- 可以选择接收时事通讯,但不一定是会员。
我想开始存储邮件列表用户的首选项。 我的问题是合并这两个表数据的最佳方法是什么?
我已经尝试过仅存储成员信息(如用户名、密码等)的成员表和存储电子邮件地址和首选项的单独的配置文件表。 成员和邮件列表首选项都可以存储在此配置文件表中,但我无法添加 FK 约束,因为我无法添加邮件列表。
所以现在我的选择是:
- 坚持使用两个表,但在邮件列表表上引入重复的“首选项”列。
- 使用单一轮廓表和螺钉参照完整性。
或者也许还有其他更好的方法?
I have a 2 tables: a membership table and mailing list table.
[Members]
Username
Password
EmailAddress
MailingListOptIn [bit]
Planes [bit]
Boats [bit]
Cars [bit]
- The fruits columns are user preferences.
and
[MailingList]
EmailAddress
MailingListOptIn
- A mailinglist'er can opt to receive newsletters but may not necessarily be a member
I would like to start storing preferences for mailinglist'ers. My question is what would be the best way to consolidate these 2 tables data?
I've experimented with the members table storing only member info like username, password etc and a separate profiles table storing the email address and preferences. Both members and mailing list preferences can be stored in this profile table but I can't add an FK constraint cause then I can't add a mailinglist'er.
So right now my options are:
- Stick with the 2 tables but introduce duplicate "preferences" columns on the mailinglist table.
- Use the single profiles table and screw referential integrity.
Or maybe there is another better way?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我会这样做:
i)一个以电子邮件地址为键的“人”表
ii)一个“成员”表,只有成员才会在此表中拥有记录,通过电子邮件地址链接到“人”(也在此键入)表)
iii)“mailingList”表,具有邮件列表的唯一 id、描述以及可能的其他字段
iv)“mailingListSubscriber”表(关系),其中包含人员的电子邮件地址和邮件列表的 id。
抱歉添加表格,但我认为这是满足要求的充分标准化的最低设置。
I would do it like this:
i) a "person" table with the email address as key
ii) a "member" table, only members will have a record in this table, linked to "person" by emailaddress (also key in this table)
iii) a "mailingList" table, having a unique id for the mailingList, the description and maybe other fields
iv) a "mailingListSubscriber" table (a relationship) with the email address of the person and the id of the mailing list.
Sorry for adding tables but I think it's the minimal setting for adequate normalization given the requirements.