数据库效率

我有两种方法可以设置我的数据库，我可以在两种方式中看到好处，但我不确定哪种方式被认为是“正确的方式”。它涉及一个赞助系统，就像Youtube风格，以便为我的网站说明一样。数据库效率

表格布局（基本的例子）表格布局

USER = user_id, etc<br> 
PROJECT = project_id, user_id, etc<br> 
PROJECTLIKE = project_like_id, project_id, user_id etc<br> 
PROJECTDISLIKE = project_dislike_id, project_id, user_id etc

设想二（基本的例子）

USER = user_id, etc,<br> 
PROJECT = project_id, user_id, etc<br> 
PROJECTLIKEDISLIKE = project_dislikelike_id, project__id, user_id, like (boolean), etc

我觉得第一个会更有效率，但第二个将

第一个想法更容易编写代码。有更好的方法还是只是偏好？

问候

来源

2014-09-19 Mike

数据库应根据数据的使用方式进行设计。您的问题没有说明使用模式。 – 2014-09-19 19:24:45

我明白你的意思了，谢谢你的回复 – Mike 2014-09-19 19:55:46

这个问题似乎是题外话题，因为它是关于设计而不是编码..没有足够的信息甚至没有给出设计建议 – ErstwhileIII 2014-09-19 22:45:35

考虑你不太喜欢和不喜欢的东西的同时，为“工程亲和力”可能做的工作单个表。

这也有更多选择的优势：“喜欢”，“不喜欢”，甚至“唔”可以很容易地包括在内。

除非每个连接表存储不同类型的信息，否则在相同的两个实体之间有多个连接表很不方便。

来源

2014-09-19 19:24:30 tadman

感谢您的回复，这是一个很好的例子，它影响了我一张桌子。这两个表的解决方案在数据库更改的标准化方面会更具前途（如果有意义的话）。 – Mike 2014-09-19 19:51:01

这两个表解决方案会更麻烦，维护和未来证明也更少，也意味着查询两个不同的表找出某人对某事的看法是什么，这会使你可能有的任何JOIN操作复杂化，这违反了[Zero，One or Infinity Rule]（http://en.wikipedia.org/wiki/Zero_one_infinity_rule ）。没有两个。 – tadman 2014-09-19 20:09:04

你可能会想

CREATE TABLE vote_types (
    vote_type INT, 
    vote_type_desc VARCHAR(32) 
); 

CREATE TABLE project_votes (
    project_id BIGINT, 
    user_id BIGINT, 
    vote INT, 
    PRIMARY KEY (project_id, user_id) 
); 

CREATE INDEX project_votes_aggregated (project_id, vote); 

SELECT vote, count(*) FROM project_votes WHERE project_id = ? GROUP BY vote;

该索引将放慢插入了一点，但作出这样的SELECT非常快。在这里，你如何索引事物实际上是效率的关键。这个模式更像是一个规范化问题。

来源

2014-09-19 19:37:01

更多的conecpt问题比任何需要的代码，但谢谢你的回复 – Mike 2014-09-19 19:42:39

回答

相关问题