Question

我正在为项目创建数据库。

在阅读数据库设计时，请记住这不是我的强项。

我有一个事件表和一个用户表，每个用户都可以创建任意数量的事件。我的问题是，设计这个表的最佳方法是什么。

目前的设计如下;

每个用户可能会有非常多的事件，所以我认为PK只有event_id才能在实际应用程序中提供足够数量的记录因此，DB的设计如下，user_id是PK的一部分;

event(**event_id**, **user_id**, event_name...etc)
user(**user_id**, first_name...etc)

然而，生成event_id + user_id作为事件的唯一标识符是非常具有挑战性的，似乎唯一的方法（使用MySQL / innodb atleast）是存储过程/触发器/在ORM框架中处理它我已经许多人建议尽可能避免使用（ORM除外）。

这是设计此表的错误方法吗？我应该在事件和用户之间有一个中间表来解决这个问题吗？

因此架构变得像;

user_event(**event_id**, **user_id**)
event(**event_id**, event_name...etc)
user(**user_id**, first_name...etc)

在这种情况下，我可以在user_id和event_id上都有auto_increment，并在user_event中创建一条记录来链接这两个记录（这种方式需要更多的数据库读取）。此外，这张表最终会有很多记录。

您对此有何看法和建议？

感谢。

Answer 1

我不打算详尽无遗地设计数据库设计，但我认为（希望）这种综合可以帮到你。我刚把它写下来：

1）表格与另一个表格的关系可以是1：n。 因此，在您的情况下，如果用户可以有n个事件，但该事件“仅属于”一个用户，则可以这样排列表格

CREATE TABLE USERS(USER_ID BIGINT NOT NULL AUTO_INCREMENT
,  FIRST_NAME ...)
;
ALTER TABLE USERS ADD PRIMARY KEY (USER_ID)
;

CREATE TABLE EVENTS (EVENT_ID BIGINT NOT NULL AUTO_INCREMENT
, USER_ID BIGINT
, ...);

ALTER TABLE EVENTS ADD PRIMARY KEY (EVENT_ID)

可能：

ALTER TABLE EVENTS ADD FOREIGN KEY (USER_ID) REFERENCES USERS(USER_ID);

2）表格与另一个表格的关系可以是n：m。 因此，在您的情况下，如果用户可以拥有m个事件但是同一事件可以链接到其他用户，则可以这种方式排列表，在大多数数据库中使用通常称为“桥表”的第三个表

CREATE TABLE USERS(USER_ID BIGINT NOT NULL
,  FIRST_NAME ...)
;
ALTER TABLE USERS ADD PRIMARY KEY (USER_ID)
;

CREATE TABLE EVENTS (EVENT_ID BIGINT NOT NULL
,  ...);
ALTER TABLE EVENTS ADD PRIMARY KEY (EVENT_ID)
;


CREATE TABLE BR_USERS_EVENTS(USER_ID BIGINT NOT NULL
, EVENT_ID BIGINT NOT NULL);
ALTER TABLE BR_USERS_EVENTS ADD PRIMARY KEY (USER_ID, EVENT_ID)
;

可能：

 ALTER TABLE BR_USERS_EVENTS ADD FOREIGN KEY (USER_ID) REFERENCES USERS(USER_ID);
 ALTER TABLE BR_USERS_EVENTS ADD FOREIGN KEY (EVENT_ID) REFERENCES EVENTS(EVENT_ID);

我应该使用用户ID和事件ID作为复合主键

1 个答案: