关于将 2 种不同类型的 ID 与一条信息相关联的 SQL 架构设计问题

发布于 2024-11-30 04:06:18 字数 1071 浏览 1 评论 0 原文

我正在努力重新设计我们架构的某些部分,但我遇到了一个问题,我只是不知道做某事的良好干净方法。我有一个事件表,例如:

Events
--------
event_id

对于每个事件,可能有 n 个与其关联的组或用户。因此,有一个将事件与用户相关的表来反映一对多关系,例如:

EventUsers
----------
event_id
user_id

问题是我们还有组的概念。除了用户之外,我们还希望将 n 个组与事件联系起来。因此,user_id 列是不够的,因为我们需要存储可能的 user_id 或 group_id。

我想了很多种方法来处理这个问题,但它们看起来都像是一个大黑客。例如,我可以将其设为参与者 ID 并放入参与者类型列中,例如:

EventUsers
----------
event_id
participant_id
participant_type

如果我想获取 user_id 10 所属的事件,则可能类似于:(

select event_id
from EventUsers 
where participant_id = 10 
and participant_type = 1

假设某个地方参与者类型 1 被定义为用户)。但从哲学的角度来看,我不喜欢这样,因为当我查看数据时,我不知道participant_id中的数字意味着什么,除非我也查看particpant_type中的值。

我还可以将 EventUsers 更改为类似以下内容:

EventParticipants
-----------------
event_id
user_id
group_id

如果该记录正在处理其他类型的信息,则允许 user_id 和 group_id 的值为 NULL。

当然,我可以将 EventUsers 分解,我们将其称为 EventGroups 到 2 个不同的表中,但如果有一种良好的逻辑方法来做到这一点,我希望将与事件相关的人员存储在一个位置。

那么,我是否忽略了实现这一目标的好方法?

I'm working on redesigning some parts of our schema, and I'm running into a problem where I just don't know a good clean way of doing something. I have an event table such as:

Events
--------
event_id

for each event, there could be n groups or users associated with it. So there's a table relating Events to Users to reflect that one to many relationship such as:

EventUsers
----------
event_id
user_id

The problem is that we also have a concept of groups. We want to potentially tie n groups to an event in addition to users. So, that user_id column isn't sufficient, because we need to store potentially either a user_id or a group_id.

I've thought of a variety of ways to handle this, but they all seem like a big hack. For example, I could make that a participant_id and put in a participant_type column such as:

EventUsers
----------
event_id
participant_id
participant_type

and if I wanted to get the events that user_id 10 was a part of, it could be something like:

select event_id
from EventUsers 
where participant_id = 10 
and participant_type = 1

(assuming that somewhere participant_type 1 was defined to be a User). But I don't like that from a philosophical point of view because when I look at the data, I don't know what the number in participant_id means unless I also look at the value in particpant_type.

I could also change EventUsers to be something like:

EventParticipants
-----------------
event_id
user_id
group_id

and allow the values of user_id and group_id to be NULL if that record is dealing with the other type of information.

Of course, I could just break EventUsers and we'll call it EventGroups into 2 different tables but I'd like to keep who is tied to an event stored in one single place if there's a good logical way to do it.

So, am I overlooking a good way to accomplish this?

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

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

发布评论

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

评论(3

夏九 2024-12-07 04:06:18

表“事件”、“用户”和“组”代表基本实体。它们通过EventUsers、GroupUsers 和EventGroups 相关。您需要将结果合并在一起,例如,活动的参加者是:

select user_id
  from EventUsers
  where event_id = @event_id
union
select GU.user_id
  from EventGroups as EG inner join
    GroupUsers as GU on GU.group_id = EG.group_id
  where EG.event_id = @event_id

不要羞于创建额外的表来表示不同类型的事物。将它们组合起来(例如使用并集)通常比尝试整理一堆模糊数据更容易。

Tables Events, Users and Groups represent the basic entities. They are related by EventUsers, GroupUsers and EventGroups. You need to union results together, e.g. the attendees for an event are:

select user_id
  from EventUsers
  where event_id = @event_id
union
select GU.user_id
  from EventGroups as EG inner join
    GroupUsers as GU on GU.group_id = EG.group_id
  where EG.event_id = @event_id

Don't be shy about creating additional tables to represent different types of things. It is often easier to combine them, e.g. with union, than to try to sort out a mess of vague data.

奢华的一滴泪 2024-12-07 04:06:18

当然,我可以将 EventUsers 分解,我们将其称为 EventGroups 到 2 个不同的表中

这是良好的逻辑方法。为每个多对多关系创建一个联结表;一个用于事件和用户,另一个用于事件和组。

Of course, I could just break EventUsers and we'll call it EventGroups into 2 different tables

This is the good logical way to do it. Create a junction table for each many-to-many relationship; one for events and users, the other for events and groups.

十雾 2024-12-07 04:06:18

这个问题没有正确的答案(尽管我确信如果你足够仔细的话,你会发现一些纯粹主义者相信他们的方法是正确的)。

就我个人而言,我喜欢第二种方法,因为它允许您提供准确反映其包含的数据的列名称。这使得您的 SELECT 语句(特别是在加入时)更容易理解。是的,您最终会在未使用的列中得到一堆 NULL 值,但这并不是什么大问题。

但是,如果您要经常加入该表,那么采用第一种方法可能是明智的选择,以便您加入的列始终相同。此外,如果您预计将来会添加新类型的 participant,这将导致 EventParticipants 中出现第三列,那么您可能需要使用第一种方法保持桌子狭窄。

There's no correct answer to this question (although I'm sure if you look hard enough you'll finds some purists that believe that their approach is the correct one).

Personally, I'm a fan of the second approach because it allows you to give columns names that accurately reflect the data they contain. This makes your SELECT statements (in particular when it comes to joining) a bit easier to understand. Yeah, you'll end up with a bunch of NULL values in the column that is unused, but that's not really a big deal.

However, if you'll be joining on this table a lot, it might be wise to go with the first approach, so that the column you join on is consistently the same. Also, if you anticipate new types of participant being added in the future, which would result in a third column in EventParticipants, then you might want to go with the first approach to keep the table narrow.

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