与数据库表中的原子性相关的问题

时间:2011-05-17 14:29:00

标签: database database-design database-schema database-normalization

我正在创建一个论坛页面,我已为其创建了以下数据库架构:

Forum(questionId, postedByUserId, questionSubject, questionBody, TagIds);

Tags(tagId, tagName);

论坛中的参赛作品将是:

(1, 1, 'sample subject', 'sample body', '1 4 2') ...

标签的示例条目将是:

(1, 'C'), (2, 'C++'), (3, 'Java'), (4, 'Data Structure') ...

现在的问题是,第一个普通形式表示所有字段都应该是原子的,在这种情况下不满意,但我认为空间被保存,好像我正在创建一个forum_tag(questionId, tagId);的新表,那么我认为这将在数据库上占用更多空间,但在概念上是正确的。

所以我不知道我该怎么做才能做我现在正在做的事情,或者按照规范化使coloumns成为原子。

请解释哪个更好,为什么因为有很多情况我发现了这样的问题但是我一直都很暧昧,我应该怎么做!

所以请帮忙。

提前致谢:)

3 个答案:

答案 0 :(得分:1)

数据库中的空间很便宜。检索时间随着空间的变化而变得便宜得多。 但是,检索时间也会受到键控访问策略是否有效的影响,并且将由查询优化器选择。效果可能是戏剧性的。

考虑您提出的架构的以下检索:找到其中一个相关标签为“4”的所有论坛条目。对于大多数DBMS,此查询将需要对整个“论坛”表进行逐步扫描。根据数据量,这可能是数百万个磁盘I / O.

现在考虑一个联结表

ForumTags (ForumId, TagId) primary key (ForumId, TagId)

此外,假设除了自动索引(ForumId,TagId)之外还有TagId的索引

同一个查询会导致其中一个索引中的值为“4”的索引查找,并且只需要十几个磁盘I / O.

规范化的目标之一是对所有数据进行键控访问。第一个正常形式是根据该目标。

我有过现实生活中的情况,可以将第一个普通形式或更好的模式与具有嵌入式列表的模式进行比较。这些情况下的速度差异大约为50比1。

答案 1 :(得分:1)

我会让你的领域成为原子。大多数情况下,您有一个将值混淆到一个字段的字段,当您不得不经常将数据分开以进行报告或分析时,您最终会感到头痛。如果你想做一些像计算你的标签一样简单的事情怎么办?由于非原子数据,您甚至无法快速SELECT COUNT()。创建具有不同标记的参考论坛帖子的查询也存在很大问题。假设您想要查询标记为“programming”的所有论坛帖子?

当您尝试查询或分析数据时,预先使数据处于原子状态会使 更容易在未来发挥作用。换句话说,数据在进入数据库之前就会开始泛化,但是你总是想从中获取具体信息。尝试将数据保持在离散的块中,以便更容易获得具体信息。

答案 2 :(得分:0)

您应该制作第三个表格来表示论坛与标签之间的关系:

ForumTags(ftID,论坛,标签)

这样,您的数据库已正确规范化,因此向论坛添加和删除标记变得更加容易。不要担心它可能在数据库中占用的额外空间,比如Walter Mitty所说:空间很便宜,检索更少。作为一般规则:规范化总是一个好主意,除非另有明确证明