2014-01-24 39 views
0

这个问题的主题是维护用户对我网站的评论。数据库表之间的数据库设计和连接操作

我在我的网站(不同类别)上有大约25000篇文章,每篇文章的下方都有一个评论部分。由于评论数量增加了超过70,000篇,我决定根据文章类别articles_of_type_category将文章分成不同的表格相应的意见表article_category_comments为每个表,假设它会提高未来的业绩(尽管目前其工作的罚款)

现在我有两个问题:

1)如果我把数据库还是会有不如果桌子尺寸进一步增大,表现会降低? 2)如果是的话,那么在新的数据库设计中,我有一些SQL连接操作的问题。在每篇文章的评论页面上,我会显示评论,发表评论的人的名字和他的观点。

因此,假设用户正在观看物品3,因此我需要获得以下详细通过连接这三个表

user_details

+----+--------+----------+ 
| id | name | college | 
+----+--------+----------+ 
| 1 | naveen | a  | 
| 2 | rahul | b  | 
| 3 | dave | c  | 
| 4 | tom | d  | 
+----+--------+----------+ 
物品3

------------------------------------------------------------------------------------------- 
serial#| comment | name_who_made_this_comment | points | gold | silver | bronze 
------------------------------------------------------------------------------------------- 
     |   |       |   |  |   | 
     |   |       |   |  |   | 

的网页上,以显示

score(此表存储用户点,如计算器)

+----+--------+------+--------+--------+---------+ 
| id | points | gold | silver | bronze | user_id | 
+----+--------+------+--------+--------+---------+ 
| 1 | 2354 | 2 |  9 |  25 | 3 | 
| 2 | 4562 | 1 |  9 |  11 | 2 | 
| 3 | 1123 | 7 |  9 |  11 | 1 | 
| 4 | 3457 | 0 |  9 |  4 | 4 | 
+----+--------+------+--------+--------+---------+ 

comments(该表存储评论,在它被做了文章的ID和用户ID)

+----+----------------------------+-------------+---------+ 
| id | comment     | article_id | user_id | 
+----+----------------------------+-------------+---------+ 
| 1 | This is a nice article  |   3 |  1 | 
| 2 | This is a tough article |   3 |  4 | 
| 3 | This is a good article  |   2 |  7 | 
| 4 | This is a good article  |   1 |  3 | 
| 5 | Please update this article |   4 |  4 | 
+----+----------------------------+-------------+---------+ 

我想是这样

select * from comments join (select * from user_details join points where user_details.id=points.user_id)as joined_temp where comments.id=joined_temp.u_id and article_id=3; 
+0

这样,“根据文章的类别articles_of_type_category将文章分成不同的表格”听起来很糟糕。我建议您的文章表中的类别表和类别标准的规范化设计。 –

+0

@DanBracuk:如果您通过命名表和相应的列名来给出概述,这将非常有用 –

+0

您可以使用该子查询来完成此任务,但您也可以直接使用user_details和points来加入注释。我怀疑引擎生病创建了一个非常不同的查询计划,但不痛尝试。 – jean

回答

1

这是为了对此作出回应评论“@DanBracuk:如果您通过命名表格和相应的列名进行概述,这将非常有用”

Table category 
categoryId int not null, autoincrement primary key 
category varchar(50) 

样本类别可能是“童话”,“第一次世界大战”或“电影明星”。

Table article 
articleId int not null, autoincrement primary key 
categoryId int not null foreign key 
text clob, or whatever the mysql equivalent is 

由于评论是为了回应我对文章和类别的评论,所以此答案仅限于此。

1

我会从一张带有文章和类别的表开始。然后使用桥接表来链接两者。我的建议是索引桥表中的类别。这将加速访问。表结构的

实施例:

CREATE TABLE Article (
id int NOT NULL AUTO_INCREMENT PRIMARY KEY, 
title varchar(100) NOT NULL 
); 

INSERT INTO Article 
    (title) 
VALUES 
('kljlkjlkjalk'), 
('aiouiwiuiuaoijukj'); 

CREATE TABLE Category (
    id int NOT NULL AUTO_INCREMENT PRIMARY KEY, 
    name varchar(100) 
); 

INSERT INTO Category 
    (name) 
VALUES 
('kljlkjlkjalk'), 
('aiouiwiuiuaoijukj'); 


CREATE TABLE Article_Category (
    id int NOT NULL AUTO_INCREMENT PRIMARY KEY, 
    article_id int, 
    category_id int 
); 

INSERT INTO Article_Category 
    (article_id, category_id) 
VALUES 
(1,1), 
(1,2); 

CREATE TABLE User_Details 
    (`id` int, `name` varchar(6), `college` varchar(1)) 
; 

INSERT INTO User_Details 
    (`id`, `name`, `college`) 
VALUES 
    (1, 'naveen', 'a'), 
    (2, 'rahul', 'b'), 
    (3, 'dave', 'c'), 
    (4, 'tom', 'd') 
; 

CREATE TABLE Score 
    (`id` int, `points` int, `gold` int, `silver` int, `bronze` int, `user_id` int) 
; 

INSERT INTO Score 
    (`id`, `points`, `gold`, `silver`, `bronze`, `user_id`) 
VALUES 
    (1, 2354, 2, 9, 25, 3), 
    (2, 4562, 1, 9, 11, 2), 
    (3, 1123, 7, 9, 11, 1), 
    (4, 3457, 0, 9, 4, 4) 
; 

CREATE TABLE Comment 
    (`id` int, `comment` varchar(26), `article_id` int, `user_id` int) 
; 

INSERT INTO Comment 
    (`id`, `comment`, `article_id`, `user_id`) 
VALUES 
    (1, 'This is a nice article', 3, 1), 
    (2, 'This is a tough article', 3, 4), 
    (3, 'This is a good article', 2, 7), 
    (4, 'This is a good article', 1, 3), 
    (5, 'Please update this article', 4, 4) 
; 

尝试这种情况:

SQLFiddle Demo

好运。

0

70000个元素并不是很多。事实上,这个数字几乎没有。你的问题在于糟糕的设计。我有一个包含数百万条记录的表,当我向后端执行复杂查询的应用程序服务器发出请求时,它的响应时间不到一秒钟。所以你绝对在做次优设计。我认为详细的答案需要太多的空间和努力(因为我们有一个完整的科学建立在你的问题上),这是超出了本网站的范围,所以我选择指向你正确的方向:

  1. 了解标准化(1NF,2NF,3NF,BCNF等)并将其与您的设计进行比较。

  2. 阅读关于索引和其他隐优化

  3. 优化你的查询,并尽量减少查询

的数量来回答您的具体问题:不,你不应该“分”你的表。您应该修复数据库模式中的结构错误,并使用数据库优化算法。