数据库设计按列表和公司对联系人进行分组

发布于 2024-09-04 14:31:52 字数 1281 浏览 4 评论 0原文

我想知道按公司对联系人进行分组的最佳方式是什么。现在,用户可以按自定义创建的列表对联系人进行分组,但我希望能够按公司对联系人进行分组,并存储联系人的位置(即< em>XYZ 公司项目经理)。

就数据库而言,这就是我将联系人分组到列表中的方法

联系方式
[id_contact] [int] PK NOT NULL,
[姓氏] [varchar] (128) NULL,
[名字] [varchar] (128) NULL,
……

联系人列表
[id_contact] [int] FK,
[id_list] [int] FK,

列表
[id_list] [int] PK
[id_user] [int] FK
[列表名称] [varchar] (128) NOT NULL,
[描述] [TEXT] NULL

我是否应该实施类似的方法来按公司对联系人进行分组?如果是这样,我将如何存储联系人在该公司的职位,以及如果用户修改联系人的公司名称,我如何防止数据损坏。例如,约翰·多伊换了公司,但其他同事仍然在原来的公司。

我怀疑这种情况会经常发生(甚至可能根本不会发生),但安全总比后悔好。我还保留了审计跟踪,因此在某种程度上,联系人仍然需要与旧公司和新公司相关联,但又不会混淆他目前实际工作的公司。

我希望这是有道理的...有人遇到过这样的问题吗?


更新

这样的事情有意义吗

contact_company
[id_contact_company] [int] PK
[id_contact] [int] FK
[id_company] [int] FK
[联系人标题] [varchar] (128)

公司
[id_company] [int] PK NOT NULL,
[公司名称] [varchar] (128) NULL,
[公司描述] [varchar] (300) NULL,
[创建日期] [日期时间] NOT NULL

这样,一个联系人可以为多个公司工作,并且可以按公司对联系人进行分组

I'm wondering what would be the best way to group contacts by their company. Right now a user can group their contacts by custom created lists but I'd like to be able to group contacts by their company as well as store the contact's position (i.e. Project Manager of XYZ company).

Database wise this is what I have for grouping contacts into lists

contact
[id_contact] [int] PK NOT NULL,
[lastName] [varchar] (128) NULL,
[firstName] [varchar] (128) NULL,
......

contact_list
[id_contact] [int] FK,
[id_list] [int] FK,

list
[id_list] [int] PK
[id_user] [int] FK
[list_name] [varchar] (128) NOT NULL,
[description] [TEXT] NULL

Should I implement something similar for grouping contacts by company? If so how would I store the contact's position in that company and how can I prevent data corruption if a user modifies a contact's company name. For instance John Doe changed companies but the other co-workers are still in the old company.

I doubt that will happen often (might not even happen at all) but better be safe than sorry. I'm also keeping an audit trail so in a way the contact would still need to be linked to the old company as well as the new one but without confusing what company he's actually working at the moment.

I hope that made sense... Has anyone encountered such a problem?


UPDATE

Would something like this make sense

contact_company
[id_contact_company] [int] PK
[id_contact] [int] FK
[id_company] [int] FK
[contact_title] [varchar] (128)

company
[id_company] [int] PK NOT NULL,
[company_name] [varchar] (128) NULL,
[company_description] [varchar] (300) NULL,
[created_date] [datetime] NOT NULL

This way a contact can work for more than one company and contacts can be grouped by companies

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

ゞ花落谁相伴 2024-09-11 14:31:52

您所拥有的更新内容看起来不错。

因此,在我看来,您有用户,每个用户都有一个联系人主列表。用户还具有用于组织主列表内的联系人的进一步列表。每个联系人都有他们的姓名和联系信息以及他们曾工作过的几家公司,此外他们还必须跟踪他们当前的公司。

将公司放在单独的表中是个好主意。通常,文本字段就可以,但由于您计划更多地使用公司作为单独的实体,因此单独的表效果最好。

我觉得我在重复你所拥有的,但我会提出看起来最好的设置。我只是按照我的约定编写以下内容(下划线表示一对多):

*user*
id [int PK], 
... 

*user_contact*
id [int PK], 
user [int FK (user)], 
currentCompany [int FK (company)] 
... 

*user_contact_company*
id [int PK], 
contact [int FK (user_contact)], 
company [int FK (company)], 
startDate [date],
endDate [date]
...

*user_contactList*
id [int PK],
user [int FK (user)]
... 

*user_contactList_contact*
id [int PK], 
contactList [int FK (user_contactList)], 
contact [int FK (contact)] 
...

*company*
id [int PK] 
... 

然后,对于基本分组:

SELECT * FROM `user_contact` WHERE `user` = <USER_ID> GROUP BY `currentCompany`

但我认为这不会按照您想要的方式工作,因此您可以有两个查询:

SELECT DISTINCT `currentCompany` FROM `user_contact` WHERE `user` = <USER_ID>

然后对于每个公司:

SELECT * FROM `user_contact` WHERE `company` = <COMPANY>

还有许多其他方法可以实现此目的,具体取决于您计划如何实施。例如,您可以只执行 ORDER BY,以便将所有公司分组在一起,然后显示公司的代码可以查看当前公司是否与以前的公司不同,并做出正确的区分。

至于公司职位,您可以考虑使用文本或引用另一个表格,具体取决于您如何使用它。如果您要进行排序,以便“项目经理”将与其他“项目经理”分组,那么它应该位于另一个表中,否则有人可能会选择与项目经理不同的名称,或者将名称设为小写,即使它们在语义上是相同的。

What you have along with the update looks about right.

So, as I see it, you have users, and each user has a master list of contacts. A user also has further lists for organizing contacts within the master list. Each contact has their name and contact information along with several companies they have worked for, plus they must keep track of their current company.

Keeping the companies in a separate table was a good idea. Normally a text field would work, but because you plan to use companies more as individual entities, a separate table works best.

I feel like I'm repeating what you have, but I'll put what seems the best setup. I'm just writing the following with my conventions (an underscore means one to many):

*user*
id [int PK], 
... 

*user_contact*
id [int PK], 
user [int FK (user)], 
currentCompany [int FK (company)] 
... 

*user_contact_company*
id [int PK], 
contact [int FK (user_contact)], 
company [int FK (company)], 
startDate [date],
endDate [date]
...

*user_contactList*
id [int PK],
user [int FK (user)]
... 

*user_contactList_contact*
id [int PK], 
contactList [int FK (user_contactList)], 
contact [int FK (contact)] 
...

*company*
id [int PK] 
... 

Then, for a basic grouping:

SELECT * FROM `user_contact` WHERE `user` = <USER_ID> GROUP BY `currentCompany`

But I don't think that would work the way you'd like, so you could have two queries:

SELECT DISTINCT `currentCompany` FROM `user_contact` WHERE `user` = <USER_ID>

Then for every company:

SELECT * FROM `user_contact` WHERE `company` = <COMPANY>

There are many other ways to do this, depending on how you're planning to implement it. For example, you could just do an ORDER BY, so all the companies are grouped together, and then your code that's displaying the companies can see if the current company is different than the previous company, and make the right distinction.

As for company positions, you could consider either doing text or referencing another table, depending on how you're using it. If you're going to do sorts, such that "Project Manager" will be grouped with other "Project Manager"s, then it should be in another table, otherwise someone might pick a different name than Project Manager, or make a name lowercase, even though they're semantically the same.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文