MySQL模式设计:一个类型列与多个表的表

时间:2018-08-04 13:19:49

标签: mysql sql

我正在建立一个有关电影的网站,我想在电影和演员(导演,作家和演员)之间建立一种关系,我有两种实现方式,第一种是创建一张每个演员:

CREATE TABLE director(id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50));  
CREATE TABLE writer(id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50));  
CREATE TABLE actor(id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50));

并在每个表和电影表之间建立多对多关系。
第二种可能性是使用类型列为演员表创建一个表,该列可以引用导演,作家或演员,并在该表和电影表之间建立多对多关系。

CREATE TABLE cast(id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50), type varchar(10));

注意:对于参与者,自动生成表将具有一些其他列:character_name,role ...
那么哪种情况更适合这种情况?

3 个答案:

答案 0 :(得分:2)

我会采用第二种方法。它甚至符合标准的SQL规则。

如果类型转换(导演,写作者等)还具有一些其他属性(列),则可以进行一些修改。在这种情况下,建议将它们作为主表的子表。

在您的情况下,主表将为“ cast”。它将具有ID和其他列。其他表将被创建并对应于不同的转换成员,例如表:“ director”,“ writter”等。然后,在每个子表之间与主“ cast”表进行1-1关系。该关系在子表上是强制性的(意味着,例如,“导演”在创建时必须与“ cast”具有关系)。从关系的意义上说,“导演”的外键也将是它的主键,并且暗示“演员”的主键。

推荐这种方法,因为不仅可以将其他列添加到不同的转换成员,而且还可以将其他关系添加到以后要扩展数据库的情况。您还可以添加“ cast”的其他子表,而无需更改相对于“电影”表的结构。

答案 1 :(得分:0)

第二种方法似乎比第一种更清洁。无需维护3个不同的表,您只需在一列中获取type

此外,您可以使用bit(0 =导演,1 =作家,2 =演员)代替varchar(10)来存储type

答案 2 :(得分:0)

两种方法都忽略了,演员,导演,作家或……(通常)是一个人。那是实际的实体。一个人在电影中扮演的角色(演员,作家等)实际上是一种关系属性。

在两种方法中都存在冗余。如果某人在电影中扮演多个角色,例如导演和表演(想起希区柯克的客串),那个人会有两张唱片。这些分布在第一个方法的两个表中,第二个方法的一个表中。一个人的属性(例如姓名等)将被存储两次,并且可能彼此矛盾,或者如果两个地方都发生更改,则两个地方都需要更改。

因此,我建议第三种方法:有一个供人使用的表,用于存储人可以拥有的所有属性(名称,...)。并有一个表格将人们链接到电影,还可以指示一个人在电影中所扮演的角色(演员,导演等)。

拥有一个角色表可能也不是坏主意。

例如:

CREATE TABLE people
             (id integer AUTO_INCREMENT,
              name varchar(50),
              PRIMARY KEY (id));

CREATE TABLE roles
             (id integer AUTO_INCREMENT,
              name varchar(10),
              PRIMARY KEY (id));

CREATE TABLE movies_people
             (movie integer,
              person integer,
              role integer,
              PRIMARY KEY (movie,
                           person,
                           role),
              FOREIGN KEY (movie)
                          REFERENCES movies
                                     (id)
                          ON DELETE CASCADE,
              FOREIGN KEY (person)
                          REFERENCES people
                                     (id),
              FOREIGN KEY (role)
                          REFERENCES roles
                                     (id));