数据库中两个表之间更灵活的关系?
more flexible relationship between two tables in database?
假设有两个table。(我举个例子table只是为了解释我的想法的概念,会有一些错误定义它。)
表A 'user'
CREATE TABLE user
(
id serial PRIMARY KEY
name character varying(80) UNIQUE NOT NULL,
)
表B 'history'
CREATE TABLE history
(
id serial PRIMARY KEY,
action character varying(80) NOT NULL,
CONSTRAINT history_action_key UNIQUE (name)
)
我认为有两种方法可以在两个 table 之间建立关系。
一种方式 : 一次添加 ForeignKey 约束 table
CREATE TABLE user
(
id serial PRIMARY KEY,
name character varying(80) NOT NULL UNIQUE,
history_id integer REFERENCES history
)
表示在用户table中还有一个名为history_id的字段指向相关的历史记录。对吗?
第二种方式:您正在创建新的table(比方说TableC 'relationship')。 TableC 将仅显示 TableA 和 TableB 之间的关系
CREATE TABLE relationship
(
id serial PRIMARY KEY,
user_id integer NOT NULL REFERENCES remann_users (id),
history_id integer NOT NULL REFERENCES history,
)
所以我的问题是
第二种方式在数据库中存储数据更灵活吗?
我觉得第二种方式似乎更灵活 因为用户table和历史table是完全分开的在个人 table 中。还有一个 table 有数据可以说明他们的关系。但第一种方式似乎用户 table 在 table 中有一个字段 'history_id'。所以我觉得它的方式更像是两个 tables.
之间的耦合
我的想法正确吗?
我想我首先对 manyTomany 关系感到困惑。
'user' table 有如下数据
pk 名称
1 约翰
2 亚当
3 凯利
'history' table 有如下数据
pk 动作
1 人打过篮球
2 人玩过电子游戏
现在我想在用户和历史记录之间建立关系。
如果 John 打 baksetball,Adam 打篮球,Kelly 打电子游戏,我可以通过在用户 table.table.
中多加一列来建立关系
'user' table
pk 名字 fk
1 约翰 1
2 亚当 1
3 凯利 2
但如果有约翰打篮球同时打电子游戏的情况。这样就成了manyTomany关系。我需要像下面这样来展示这种关系。
'user' table
pk 名称第一个动作(fk) 第二个动作(fk)
1 约翰 1 2
2 亚当 1 空
3 凯利 2 空
但这是个坏主意,因为如果您想为某个特定用户添加更多操作,则必须更改架构。例如,用户玩 baksetball、踢足球和玩视频游戏。您需要添加第三个操作 (fk),其他用户行将具有空值。
所以你可以制作另一个 table 来组合两个 table 而不会出现这个问题。这将是我上面解释的第二种方式。制作另一个 table 来显示两个 table 之间的关系只是使其在多对多情况下更有效的方法。对吗?
这是我对您的回答感到困惑的地方。 "more flexible"
更灵活意味着如果你有桥 table 像第二种方式或只是 m2m 关系更灵活,则显示 m2m 数据更灵活?我比什么都糊涂了?
It means there is another field named history_id to direct to related history with FK in user table. right?
随心所欲地命名,但可以。
I feel like second way seems more flexible because User table and History table are totally separated in individual tables. And Just another table have data to tell their relationship. But first way seems User table have a field 'history_id' in it's table. So I feel like its way is more coupling between two tables. ... Is my idea correct?
我从 我的想法 中得到了启发。是的,你是对的。您所说的 关系 table 建立了数据库管理员所说的 Many-to-many 模型。
- 更灵活。
- 也比较慢。
- 查询难度加大。
问题是一个用户是否可以拥有多个历史,如果他们不能,你为什么要制作所有您的查询更复杂以支持吗?
在正常的 M2M table 中,在 PostgreSQL 中你有这样的东西,
CREATE TABLE user (
user_id serial PRIMARY KEY,
name text NOT NULL
);
CREATE TABLE history (
history_id serial PRIMARY KEY,
tz timestamp DEFAULT NOW()
);
CREATE TABLE relationship (
user_id int REFERENCES users,
history_id integer REFERENCES history,
PRIMARY KEY (user_id, history_id)
)
- 如果一个用户有两个历史记录会怎样?
喜欢,
INSERT INTO relationship VALUES (1,1), (1,2);
- 如果我们有两个具有相同历史记录的用户会怎样?
喜欢,
INSERT INTO relationship VALUES (1,1), (2,1);
如果这些在您的应用中是不可能的,请不要使用多对多。
假设有两个table。(我举个例子table只是为了解释我的想法的概念,会有一些错误定义它。)
表A 'user'
CREATE TABLE user
(
id serial PRIMARY KEY
name character varying(80) UNIQUE NOT NULL,
)
表B 'history'
CREATE TABLE history
(
id serial PRIMARY KEY,
action character varying(80) NOT NULL,
CONSTRAINT history_action_key UNIQUE (name)
)
我认为有两种方法可以在两个 table 之间建立关系。
一种方式 : 一次添加 ForeignKey 约束 table
CREATE TABLE user
(
id serial PRIMARY KEY,
name character varying(80) NOT NULL UNIQUE,
history_id integer REFERENCES history
)
表示在用户table中还有一个名为history_id的字段指向相关的历史记录。对吗?
第二种方式:您正在创建新的table(比方说TableC 'relationship')。 TableC 将仅显示 TableA 和 TableB 之间的关系
CREATE TABLE relationship
(
id serial PRIMARY KEY,
user_id integer NOT NULL REFERENCES remann_users (id),
history_id integer NOT NULL REFERENCES history,
)
所以我的问题是
第二种方式在数据库中存储数据更灵活吗?
我觉得第二种方式似乎更灵活 因为用户table和历史table是完全分开的在个人 table 中。还有一个 table 有数据可以说明他们的关系。但第一种方式似乎用户 table 在 table 中有一个字段 'history_id'。所以我觉得它的方式更像是两个 tables.
之间的耦合我的想法正确吗?
我想我首先对 manyTomany 关系感到困惑。
'user' table 有如下数据
pk 名称
1 约翰
2 亚当
3 凯利
'history' table 有如下数据
pk 动作
1 人打过篮球
2 人玩过电子游戏
现在我想在用户和历史记录之间建立关系。
如果 John 打 baksetball,Adam 打篮球,Kelly 打电子游戏,我可以通过在用户 table.table.
中多加一列来建立关系'user' table
pk 名字 fk
1 约翰 1
2 亚当 1
3 凯利 2
但如果有约翰打篮球同时打电子游戏的情况。这样就成了manyTomany关系。我需要像下面这样来展示这种关系。
'user' table
pk 名称第一个动作(fk) 第二个动作(fk)
1 约翰 1 2
2 亚当 1 空
3 凯利 2 空
但这是个坏主意,因为如果您想为某个特定用户添加更多操作,则必须更改架构。例如,用户玩 baksetball、踢足球和玩视频游戏。您需要添加第三个操作 (fk),其他用户行将具有空值。
所以你可以制作另一个 table 来组合两个 table 而不会出现这个问题。这将是我上面解释的第二种方式。制作另一个 table 来显示两个 table 之间的关系只是使其在多对多情况下更有效的方法。对吗?
这是我对您的回答感到困惑的地方。 "more flexible" 更灵活意味着如果你有桥 table 像第二种方式或只是 m2m 关系更灵活,则显示 m2m 数据更灵活?我比什么都糊涂了?
It means there is another field named history_id to direct to related history with FK in user table. right?
随心所欲地命名,但可以。
I feel like second way seems more flexible because User table and History table are totally separated in individual tables. And Just another table have data to tell their relationship. But first way seems User table have a field 'history_id' in it's table. So I feel like its way is more coupling between two tables. ... Is my idea correct?
我从 我的想法 中得到了启发。是的,你是对的。您所说的 关系 table 建立了数据库管理员所说的 Many-to-many 模型。
- 更灵活。
- 也比较慢。
- 查询难度加大。
问题是一个用户是否可以拥有多个历史,如果他们不能,你为什么要制作所有您的查询更复杂以支持吗?
在正常的 M2M table 中,在 PostgreSQL 中你有这样的东西,
CREATE TABLE user (
user_id serial PRIMARY KEY,
name text NOT NULL
);
CREATE TABLE history (
history_id serial PRIMARY KEY,
tz timestamp DEFAULT NOW()
);
CREATE TABLE relationship (
user_id int REFERENCES users,
history_id integer REFERENCES history,
PRIMARY KEY (user_id, history_id)
)
- 如果一个用户有两个历史记录会怎样?
喜欢,
INSERT INTO relationship VALUES (1,1), (1,2);
- 如果我们有两个具有相同历史记录的用户会怎样?
喜欢,
INSERT INTO relationship VALUES (1,1), (2,1);
如果这些在您的应用中是不可能的,请不要使用多对多。