我应该如何维护 MySQL 字段中的用户列表?

发布于 2024-10-10 05:34:07 字数 280 浏览 1 评论 0原文

我有一个用户表,每个用户都有一个唯一的user_id。每个用户还有一个存储在 partner 下的合作伙伴。一名用户一次只能拥有一个伙伴,但随着时间的推移,他将拥有多个伙伴。我想为他们过去的合作伙伴的每个用户维护一个列表。 我应该如何存储这样的列表?
我想我只会有一个名为 prior_partners 的列,并且能够在其中为每个用户维护一个以逗号分隔的列表。这是一个可能的解决方案吗?这是一个好的解决方案吗?
谢谢。

I have a users table, and each user has a unique user_id. Each user also has a partner stored under partner. A user will have only one partner at a time, but he will have multiple partners of the course of time. I would like to maintain a list for every user of their past partners. How should I store such a list?
I figured I would just have a column called prior_partners and be able to maintain a comma-separated list therein for each user. Is that a possible solution? Is it a good solution?
Thanks.

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

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

发布评论

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

评论(4

风流物 2024-10-17 05:34:07

我强烈建议使用关系数据库的强大功能来跟踪此信息。我会创建另一个名为“partners”或类似名称的表,并具有三列:“user_id_1”、“user_id_2”和“start_date”(如果您愿意,可以添加“end_date”列以便于查询)。

然后,当您有合作伙伴更改时,只需插入到这个新表中(并且,如果您有“end_date”列,请相应地更新这些行)。然后,当您想要从表中提取信息时,只需使用带有子查询的联接来获取最新的合作伙伴信息,并且您将始终将更新的历史合作伙伴数据存储在数据库中。

从表面上看,这种设置方式有点复杂,但随着时间的推移,它会让你获得更多关于人与人之间关系的信息。

编辑:

您的选择查询将采用如下格式(如果您确实包含 end_date 字段,这在 mySQL 中会更容易):

SELECT u.user_id, coalesce(p1.user_id1, p2.user_id2) as current_partner_id
FROM users u
LEFT JOIN (
  SELECT user_id1, max(user_id2) as user_id2
  FROM partnerships
  WHERE end_date IS NULL
  GROUP BY user_id1
) p1 on p1.user_id1 = u.user_id
LEFT JOIN (
  SELECT max(user_id1) as user_id1, user_id2
  FROM partnerships
  WHERE end_date IS NULL
  GROUP BY user_id2
) p2 on p2.user_id2 = u.user_id

我的主要专业领域是 MS SQL 而不是 mySQL,但我相信上述内容将为您提供当前的合作伙伴对于每个用户以及该用户。

然后,如果您想查看给定用户的所有合作伙伴关系的历史记录,您可以编写如下查询:

SELECT user_2 as partner_id, begin_date, end_date
FROM partnerships
WHERE user_1 = '{your user id of interest}'

UNION

SELECT user_1 as partner_id, begin_date, end_date
FROM partnerships
WHERE user_2 = '{your user id of interest}'

ORDER BY begin_date

这将为您提供 {您感兴趣的用户 ID} 的按时间顺序排列的合作伙伴关系记录集。

我希望这有帮助!

I would highly recommend using the power of the relational database to track this information. I'd make another table called 'partners' or something similar, and have three columns: 'user_id_1', 'user_id_2', and 'start_date' (you can add an 'end_date' column for ease of querying if you like).

Then, when you have a partner change, just do an insert into this new table (and, if you've got an 'end_date' column, update those rows accordingly). Then, when you want to pull the information from the table, just use a join with a subquery that gets the most current partner information and you'll always have updated and historical partnership data stored in your database.

Setting it up this way is a little more complicated on its face, but it will allow you to pull up MUCH more information over time about the relationships between people.

edit:

Your select query would be formatted something like this (and this is easier in mySQL if you do include the end_date field):

SELECT u.user_id, coalesce(p1.user_id1, p2.user_id2) as current_partner_id
FROM users u
LEFT JOIN (
  SELECT user_id1, max(user_id2) as user_id2
  FROM partnerships
  WHERE end_date IS NULL
  GROUP BY user_id1
) p1 on p1.user_id1 = u.user_id
LEFT JOIN (
  SELECT max(user_id1) as user_id1, user_id2
  FROM partnerships
  WHERE end_date IS NULL
  GROUP BY user_id2
) p2 on p2.user_id2 = u.user_id

My primary area of expertise is MS SQL rather than mySQL, but I believe the above will get you the current partner for each user, along with that user.

Then, if you want to see the history of all partnerships for a given user, you'd write a query like this:

SELECT user_2 as partner_id, begin_date, end_date
FROM partnerships
WHERE user_1 = '{your user id of interest}'

UNION

SELECT user_1 as partner_id, begin_date, end_date
FROM partnerships
WHERE user_2 = '{your user id of interest}'

ORDER BY begin_date

This will get you a chronological recordset of partnerships for {your user id of interest}.

I hope this helps!

尝蛊 2024-10-17 05:34:07

您可能应该创建一个 partners 表,其中包含两个人的 ID 和日期。最新日期是活跃的合作伙伴关系。

+----------+
| PARTNERS |
+----------+
| user_a   | (first partner)
+----------+
| user_b   | (second partner)
+----------+
| date     | (date the partnership began)
+----------+

这是一个相当基本的例子。根据合作伙伴的具体内容,您可能还有其他领域。

合作伙伴的历史将反映为一系列行:

Fizzbuzz Socks | Noke Shoes | Jan 23, 1983
StackOverflow  | GoogleDocs | Jan 29, 1992
Fizzbuzz Socks | Life Shoes | Nov 02, 1990
Fizzbuzz Socks | Sutt Shoes | Oct 18, 1995

从中我们可以看到,Fizzbuzz 历史上有过三个合作伙伴关系,目前的合作伙伴关系是与 Sutt Shoes,开始于 1995 年 10 月 18 日。对于每一个新的合作伙伴关系,您都会创建一个新纪录。

You should probably created a partners table that takes the id of both people, and a date. The latest date is the active partnership.

+----------+
| PARTNERS |
+----------+
| user_a   | (first partner)
+----------+
| user_b   | (second partner)
+----------+
| date     | (date the partnership began)
+----------+

This is a rather basic example. Depending on what exactly a partnership is, you may have other fields.

A history of partners would reflect as a series of rows:

Fizzbuzz Socks | Noke Shoes | Jan 23, 1983
StackOverflow  | GoogleDocs | Jan 29, 1992
Fizzbuzz Socks | Life Shoes | Nov 02, 1990
Fizzbuzz Socks | Sutt Shoes | Oct 18, 1995

From this we can see that Fizzbuzz had three partnerships in history, and the present partnership is with Sutt Shoes, started on Oct 18, 1995. For every new partnership, you would create a new record.

清风夜微凉 2024-10-17 05:34:07

从长远来看,您可能最好创建一个单独的表来管理这种关系,并使用引用合作伙伴和用户的字段。也许还有其他一些字段来指示哪个关系处于活动状态。我能想到的第一个原因是,查询表中的字段比查询以逗号分隔的文本字段中的值要容易得多。

In the long run you're probably better off creating a separate table to manage this relationship, with a field referencing the partner and the user. And maybe some other field to indicate which relationship is active. The first reason I can think of is that it's much easier to query against fields in a table, than against values in a comma-separated text field.

软甜啾 2024-10-17 05:34:07

用逗号分隔的列表是一个非常糟糕的主意。当试图重新加入合作伙伴时,合作太困难了。最好创建一个新表来保存历史关系。

A comma-separated list is a very bad idea. It's too difficult to work with when trying to join back to the partners. Better to create a new table to hold the historical relationships.

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