这是我目前的Mysql结构。
2表:
1.) Movies
2.) Genres
两个表都由名为movie_id
的列连接。
以下是我的表结构示例:
<小时/> 表:
Movies
movie_id movie_name
1 Superman
2 Logan
3 The Hangover
4 8 Mile
5 The Dark Knight
表格类型
movie_id genres_name
1 Science Fiction
1 Action
1 Fantasy
1 Adventure
2 Action
2 Drama
2 Science Fiction
3 Comedy
4 Music
4 Drama
5 Crime
5 Thriller
5 Action
5 Drama
<小时/> <小时/> 现在很多人建议我将我的表格结构改为这个:
表格:电影
movie_id movie_name
1 Superman
2 Logan
3 The Hangover
4 8 Mile
5 The Dark Knight
表: Genres_id
genres_id genres_name
1 Science Fiction
2 Action
3 Fantasy
4 Adventure
5 Drama
6 Comedy
7 Music
8 Thriller
9 Crime
表格类型
movie_id genres_id
1 1
1 2
1 3
1 4
2 2
2 5
2 1
3 6
4 7
4 5
5 9
5 8
5 2
5 5
我目前正在使用第一个数据库结构。但是我应该把它改成第二个吗?但是有什么优势呢?更好的速度? (我真的需要它)
请告诉我,如果您需要更多信息,谢谢。
答案 0 :(得分:4)
第二个数据库结构具有以下优点:
通过实现参照完整性,无法为电影分配无效的类型。在第一个选项中,可以拼写错误(例如Sience Fiction
)。为了避免在第一个选项中发生这种情况,可以添加数据库约束以仅允许某些值,但列出那些将非常接近实际为其创建第三个表,并且稍后允许新类型将需要DML语句(而不是第二个选项中的简单insert
)。
当电影数据有限,并且仍然没有插入电影记录的类型时,用户无法轻易知道哪些类型可用,因为它们只是没有存储。在第一个选项中,它们可以作为约束值出现,但是没有SQL标准可以从数据库字典中检索它们。在实践中,您只需在应用程序语言中复制此知识,并在那里定义一个封闭的可能值数组。但这只是将数据责任转移到数据库之外。
占用的空间更少。数字外键值比类型文本字符串占用更少的空间。不可否认,这些字符串仍将存储在(单独的)表中,但每种类型只能存储一次。由于电影和相关的电影表通常具有比不同可能类型的数量更多的记录,因此存在空间增益。对于想要在类型上创建的索引也是如此,因此用于列出特定类型的电影的查询将有效地运行。数字索引占用的空间比文本字符串索引少。
列出所有类型的查询将更有效地运行。这是一个常见的用例,例如,当您需要填充下拉列表框以供用户选择类型时。
答案 1 :(得分:1)
检查这个:
CREATE TABLE Movies (
movie_id INT AUTO_INCREMENT PRIMARY KEY,
movie_name VARCHAR(255) NOT NULL,
UNIQUE KEY ix_movie_name (movie_name));
CREATE TABLE Genres (
genre_id INT AUTO_INCREMENT PRIMARY KEY,
genre_name VARCHAR(255) NOT NULL.
UNIQUE KEY ix_genre_name (genre_name));
CREATE TABLE Movie_Genres (
movie_id INT NOT NULL,
genre_id INT NOT NULL,
PRIMARY KEY (movie_id, genre_id),
FOREIGN KEY (movie_id) REFERENCES Movies(movie_id),
FOREIGN KEY (genre_id) REFERENCES Genres(genre_id))
);
按类型搜索名称只能通过索引查找一个类型记录。
还可以直接检索电影的类型。