博客数据库设计 博客系统的数据库需要设计哪些表

其实博客数据库设计的问题并不复杂，但是又很多的朋友都不太了解博客系统的数据库需要设计哪些表，因此呢，今天小编就来为大家分享博客数据库设计的一些知识，希望可以帮助到大家，下面我们一起来看看这个问题的分析吧！

开发人员如何有效的进行数据库设计

数据库设计在软件开发过程中占有重要的地位，国内开发者MeteorSeed在博客中结合自己的实际经历全面总结了关系型数据库设计需要注意的各个方面，包括Codd的基本法则、设计阶段、设计原则和命名规则。

MeteorSeed认为在项目早期应该由开发者进行数据库设计，后期调优则需要DBA：“一个精通OOP和ORM的开发者，设计的数据库往往更为合理，更能适应需求的变化”。他引用了关系数据库之父Codd的12条法则，作为数据库设计的指导性方针：

信息法则

关系数据库中的所有信息都用唯一的一种方式表示——表中的值。

保证访问法则

依靠表名、主键值和列名的组合，保证能访问每个数据项。

空值的系统化处理

支持空值（NULL），以系统化的方式处理空值，空值不依赖于数据类型。

基于关系模型的动态联机目录

数据库的描述应该是自描述的，在逻辑级别上和普通数据采用同样的表示方式，即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用户可以访问的表中。

统一的数据子语言法则

一个关系数据库系统可以支持几种语言和多种终端使用方式，但必须至少有一种语言，它的语句能够一某种定义良好的语法表示为字符串，并能全面地支持以下所有规则：数据定义、视图定义、数据操作、约束、授权以及事务。（这种语言就是SQL)

视图更新法则

所有理论上可以更新的视图也可以由系统更新。

高级的插入、更新和删除操作

把一个基础关系或派生关系作为单个操作对象处理的能力不仅适应于数据的检索，还适用于数据的插入、修改个删除，即在插入、修改和删除操作中数据行被视作集合。

数据的物理独立性

不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动都保持着逻辑上的不变性。

数据的逻辑独立性

当对表做了理论上不会损害信息的改变时，应用程序和终端活动都会保持逻辑上的不变性。

数据完整性的独立性

专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定义，而且可以存储在数据目录中，而非程序中。

分布独立性

不管数据在物理是否分布式存储，或者任何时候改变分布策略，RDBMS的数据操纵子语言必须能使应用程序和终端活动保持逻辑上的不变性。

非破坏性法则

如果一个关系数据库系统支持某种低级（一次处理单个记录）语言，那么这个低级语言不能违反或绕过更高级语言（一次处理多个记录）规定的完整性法则或约束，即用户不能以任何方式违反数据库的约束。、

MeteorSeed把数据库设计阶段分为规划阶段、概念阶段、逻辑阶段、实现阶段和物理阶段。关于设计原则，他从以下几个方面阐述了自己的经验：

降低对数据库功能的依赖

功能应该由程序实现，而非DB实现。原因在于，如果功能由DB实现时，一旦更换的DBMS不如之前的系统强大，不能实现某些功能，这时我们将不得不去修改代码。所以，为了杜绝此类情况的发生，功能应该有程序实现，数据库仅仅负责数据的存储，以达到最低的耦合。

定义实体关系的原则

当定义一个实体与其他实体之间的关系时，需要考量如下：

牵涉到的实体识别出关系所涉及的所有实体。

所有权考虑一个实体“拥有”另一个实体的情况。

基数考量一个实体的实例和另一个实体实例关联的数量。

关系与表数量

描述1:1关系最少需要1张表。

描述1:n关系最少需要2张表。

描述n:n关系最少需要3张表。

列意味着唯一的值

如果表示坐标（0,0），应该使用两列表示，而不是将“0,0”放在1个列中。

列的顺序

列的顺序对于表来说无关紧要，但是从习惯上来说，采用“主键+外键+实体数据+非实体数据”这样的顺序对列进行排序显然能得到比较好的可读性。

定义主键和外键

数据表必须定义主键和外键（如果有外键）。定义主键和外键不仅是RDBMS的要求，同时也是开发的要求。几乎所有的代码生成器都需要这些信息来生成常用方法的代码（包括SQL文和引用），所以，定义主键和外键在开发阶段是必须的。之所以说在开发阶段是必须的是因为，有不少团队出于性能考虑会在进行大量测试后，在保证参照完整性不会出现大的缺陷后，会删除掉DB的所有外键，以达到最优性能。MeteorSeed认为，在性能没有出现问题时应该保留外键，而即便性能真的出现问题，也应该对SQL文进行优化，而非放弃外键约束。

选择键

人工键与自然键。人工键——实体的非自然属性，根据需要由人强加的，如GUID，其对实体毫无意义；自然键——实体的自然属性，如身份证编号。人工键的好处：键值永远不变；永远是单列存储。人工键的缺点：因为人工键是没有实际意义的唯一值，所以不能通过人工键来避免重复行。MeteorSeed建议全部使用人工键。原因如下：

在设计阶段我们无法预测到代码真正需要的值，所以干脆放弃猜测键，而使用人工键。

人工键复杂处理实体关系，而不负责任何属性描述，这样的设计使得实体关系与实体内容得到高度解耦，这样做的设计思路更加清晰。

MeteorSeed的另一个建议是——每张表都需要有一个对用户而言有意义的自然键，在特殊情况下也许找不到这样一个项，此时可以使用复合键。这个键我在程序中并不会使用其作为唯一标识，但是却可以在对数据库直接进行查询时使用。使用人工键的另一个弊端，主要源自对查询性能的考量，因此选择人工键的形式（列的类型）很重要：

自增值类型，由于类型轻巧查询效率更好，但取值有限。

GUID查询效率不如值类型，但是取值无限，且对开发人员更加亲切。

智能健与非智能键。智能键——键值包含额外信息，其根据某种约定好的编码规范进行编码，从键值本身可以获取某些信息；非智能键，单纯的无意义键值，如自增的数字或GUID。智能键是一把双刃剑，开发人员偏爱这种包含信息的键值，程序盼望着其中潜在的数据；数据库管理员或者设计者则讨厌这种智能键，原因也是很显然的，智能键对数据库是潜在的风险。前面提到，数据库设计的原则之一是不要把具有独立意义的值的组合实现到一个单一的列中，应该使用多个独立的列。数据库设计者，更希望开发人员通过拼接多个列来得到智能键，即以复合主键的形式给开发人员使用，而不是将一个列的值分解后使用。开发人员应该接受这种数据库设计，但是很多开发者却想不明白两者的优略。MeteorSeed认为，使用单一列实现智能键存在这样一个风险，就是我们可能在设计阶段无法预期到编码规则可能会在后期发生变化。比如，构成智能键的局部键的值用完而引起规则变化或者长度变化，这种编码规则的变化对于程序的有效性验证与智能键解析是破坏性的，这是系统运维人员最不希望看到的。所以MeteorSeed建议如果需要智能键，请在业务逻辑层封装（使用只读属性），不要再持久化层实现，以避免上述问题。

除此之外，MeteorSeed还从“是否允许NULL”、属性切割、规范化（范式）、选择数据类型、优化并行等几个方面谈了设计原则。有关详细内容，可以查看MeteorSeed的博客原文。

开发人员如何有效的进行数据库设计

标签：代码生成器系统而不是比较存储使用原因分解分布式存储

博客系统的数据库需要设计哪些表

你一般需要作者表、文章表、类别表、评论表，

作者表用来存放注册用户信息：用户ID、用户名、密码、发表数、最后发表日期；用户ID为主键；

文章表用来存放所有文章信息：文章ID、用户ID、类别ID、标题、正文、点击数；文章ID为主键；

类别表用来存放所有文章类别信息：用户ID、类别ID、类别名称；用户ID、类别ID为主键；

评论表用来存放所有的评论：文章ID、评论ID、评论人名称、评论内容、作者回复内容；评论ID为主键；文章ID为外键；

我以前自己写的博客系统把所有人的文章分类统一进行管理，这样可以在一个总目录下分类浏览所有文章，因为我的系统在公司内部网络运行，用户不是很多。如果你也打算这样，那么分类表设计需要麻烦一点，要么管理员维护，要么作者申请、管理员审核，要么作者先直接使用，管理员负责调整。

如何进行文章分类和标签的数据库设计

几乎在所有web项目中，都涉及文章分类和标签的设计，应该说这是一个比较常见、典型的案例。站长并不保证我的思路就是最好的，只是分享出来大家一起交流一下，互相促进与提高。我们假设的开发项目是一个博客系统，最核心的部分就是与文章相关的，那么我们今天讨论如何设计博客系统的文章分类和标签。1、首先，分类和标签都是要和具体的文章相关联的，当然也可能一些文章既没有分类也没有标签，这一点是大家在写查询的时候容易疏忽的地方。因为我们的第一感觉就是，在查询文章列表的时候关联分类表，查出所有的文章和分类，对应关系一般是文章表的分类id对应分类表的id，使用where子句进行限定。这里就存在一个问题了，由于使用了where子句，那么只能查询有分类的文章，而没有分类的文章就查询不到了。这时候怎么办？应该使用连接查询，left join，这要没有分类的文章，在文章分类id那一栏会显示null。通常我们只使用left join，而很少使用right join。2、一般，一篇文章最好只对应一个分类，当然如果你想要对应多个分类也可以。但站长并不提倡，文章在多个分类中重复会给人很不专业的感觉，即使有些文章可能确实设计到多方面的内容，那么你应就其中的侧重点来分类。而标签就不一样了，一篇文章可能有多个标签。这就意味着我们无法靠一个sql语句既查出所有文章的分类和标签，又做到查询结果中的文章id不重复。通常我们需要把查询出来的结果直接循环出来，那么这个结果一般是二维数组，第二维的都存储了唯一一篇文章的相关信息。但是，标签和文章是多对一的关系，多个标签对应一篇文章，如果你只用一条sql语句的话，那么我们查询出来的结果，当然也是多行，这不符合我们目标数据的要求。应此，需要在查询完文章和分类之后，在前面结果的基础上再查询一次文章标签，把两次的结果结合起来，存在数组中，这是对应文章列表页面的查询方法。对于具体文章页面，可以分两次查询。好了，还没有给出具体的数据库设计，就先说了如何查询结果，相信大家也看烦了，下面就举例说明：一、文章表：post，字段如下：id【唯一标识】，aid【作者id】，title【标题】,content【内容】，cid【分类id】二、分类表，category，字段如下：id【唯一标识，与post表的cid关联】,name【分类名】三、标签表，tag，字段如下：id【唯一标识】，name【标签名】四、标签与文章对应关系表，tag_relationship，字段如下：id【唯一标识】，postid【文章id，与post表的id关联】，tagid【标签id，tag表的id关联】有朋友可能会问：为什么要单独用一个表来存储文章与标签的对应关系，为什么不可以直接在tag表中增加一个文章id字段呢，比如：tag表：id，postid，name这样做的话，并不是不可以，但是，由于一篇文章对应多个标签，所以name字段的值会出现很多重复，比如一篇文章，假设文章id为1，有2个标签，php和mysql，那么在tag表会这样存储：id:1,postid:1,name:phpid2,postid:1,name:mysql另一篇文章，假设id为2，有2个标签，也是php和mysql，那么在tag表中它会这样存储：id:3,postid:2,name:phpid4,postid:2,name:mysql大家很快就发现了问题，这样的设计name字段也就是标签的名称在同一张表中可能会大量重复。但是这样设计的好处是，如果你要查询一个标签下有多少篇文章，只要单独查这个表就可以了，比如要查询含有php标签的文章有多少篇，只需要select count(name)�0�2from tag where name=’php’,就可以查出来。不好的地方是，如果要查询所有标签的集合，使用这种设计需要使用group by name语句来去除重复的行。如果用之前的那种，只需要select* from tag就可以了。一时之间，好像不太好取舍。这两种设计都会有数据冢余，第一种tag_relationship表中，存在tagid字段的重复；而这两种设计又都有各自的好处。那么我们到底该怎么选择呢？站长也说不好，所以无法为大家下结论。但是站长在研究wordpress数据结构的时候，发现wp是采用的单独建表存储文章与标签对应关系的方式。另外，如何设计有时候也是取决具体功能的需求的，所以这个问题就留给大家一起来讨论吧~标签：分类和标签,博客数据库设计

文章分享结束，博客数据库设计和博客系统的数据库需要设计哪些表的答案你都知道了吗？欢迎再次光临本站哦！