整体设计

基于需求分析，我们决定为我们的博客应用使用如下数据表存储持久数据：

• tbl_user 存储用户信息，包括用户名和密码。
• tbl_post 存储博客日志信息。它由如下几列组成：
  • title: 必填项，日志的标题；
  • content: 必填项，日志的内容，使用 Markdown 格式;
  • status: 必填项，日志的状态，可以是以下值之一：
    • 1, 表示日志在草稿箱里，对外不可见；
    • 2, 表示日志已经对外发布；
    • 3, 表示日志已经过期，在日志列表中不可见（但仍然可以单独访问）。
  • tags: 可选项，用于对日志归类的一个以逗号分隔的词语列表。
• tbl_comment 存储日志评论信息，每条评论关联于一篇日志，主要包含如下几列：
  • name: 必填项， 作者名字；
  • email: 必填项， 作者 Email；
  • website: 可选项, 作者网站的 URL;
  • content: 必填项， 纯文本格式的评论内容；
  • status: 必填项， 评论状态，用于表示日志是(2)否(1)已通过审核。
• tbl_tag 存储日志Tag使用频率信息，用于实现标签云效果。此表主要包含以下几列：
  • name: 必填项， 唯一的Tag名字;
  • frequency: 必填项，Tag出现在日志中的次数。
• tbl_lookup 存储通用查找信息。它本质上是一个整型数字和文本字符的映射。前者是我们的代码中的数据表现，后者是相应的对最终用户的表现。例如，我们使用整数1表示草稿日志，而使用字符串“草稿”把此状态显示给最终用户。此表主要包含以下几列：
  • name: 数据项的文本表现形式，用于显示给最终用户；
  • code: 数据项的整数表现形式；
  • type: 数据项的类型；
  • position: 同类数据项中，数据项相对于其他数据项的显示顺序。

如下的实体-关系（ER）图展示了上述表的表结构和他们之间的关系。

上述ER图相应的完整SQL语句可以在 博客演示 中找到。在我们的安装包中，它们位于 /wwwroot/yii/demos/blog/protected/data/schema.sqlite.sql。

信息: 我们对所有表和列的命名使用了小写字母。这是因为不同的 DBMS 通常有不同的大小写敏感处理方式，我们通过这种方式来避免这种问题。

我们同时对所有的表使用了 tbl_ 前缀。这出于两个目的。第一，此前缀对这些表提供了一个命名空间以使他们和同一数据库中的其他表共存，此情况常出现在在共享的主机环境中，一个数据库常被多个应用使用。第二，使用表前缀减少了表名中出现DBMS保留字的可能。

我们把博客应用的开发划分为如下几个阶段：

• 阶段 1: 创建一个博客系统的原型。它应该包括大多数所需的功能。
• 阶段 2: 完善日志管理功能。包括日志的创建，日志列表，日志显示，日志更新和删除。
• 阶段 3: 完善评论管理功能。包括评论创建，评论列表，审核，更新以及日志评论的删除。
• 阶段 4: 实现 Portlets。它包括用户菜单，登录，标签云和最新评论Portlets。
• 阶段 5: 最终调试和部署。