数据库表之间的数据库设计和连接操作

时间:2014-01-24 17:25:15

标签: mysql sql database database-design

这个问题的主题是维护用户对我网站的评论。

我的网站(不同类别)有大约25000篇文章,每篇文章下面都有一个评论部分。由于评论数量增加了超过70,000,我决定将文章分为不同的表格,具体取决于其类别{{1每个表都有一个相应的注释表articles_of_type_category,假设它将来会提高性能(虽然目前工作正常)

现在我有两个问题:

1)如果表格的大小进一步扩大,我应该划分数据库还是不会降低性能?

2)如果是,那么我在SQL中遇到了新数据库设计的连接操作问题。在每篇文章的评论页面上,我会显示评论,发表评论的人的姓名和他的观点。

假设用户正在查看文章3,因此我需要获得以下详细信息以显示在第3条的页面上

article_category_comments

加入这三个表

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

user_details

+----+--------+----------+ | id | name | college | +----+--------+----------+ | 1 | naveen | a | | 2 | rahul | b | | 3 | dave | c | | 4 | tom | d | +----+--------+----------+ (此表存储用户点,如stackoverflow)

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 | +----+--------+------+--------+--------+---------+ (此表存储评论,制作文章的ID和用户ID)

comments

我试过像

这样的东西
+----+----------------------------+-------------+---------+
| 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 |
+----+----------------------------+-------------+---------+

3 个答案:

答案 0 :(得分: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 :(得分: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

祝你好运。

答案 2 :(得分:0)

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

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

  2. 了解索引和其他隐式优化

  3. 优化查询并最大限度地减少查询次数

  4. 至于回答你的具体问题:不,你不应该“划分”你的桌子。您应该修复数据库模式中的结构错误,并使用数据库优化算法。