高级项目日志

 1、 ^_^  ^_^  今天是项目正式开工的第一天，设计分析也就是画一些相关的UML图。 俗话说得一点都没错“万事开头难”， 忙碌了一整天但没有什么进展。  尤其使我认识到了设计并不如自己之前认为的那样是简单的， 以前具体做编码遇到困难时就会想做设计好， 做设计可以告别烦闷且沉重的体力活。

         以前也经常听前辈提起过“做软件难的不是技术”， 虽然我现在还没有深刻地体会到这点， 但是我想应该没错。 ^_^  ^_^  我自己感觉 技术 更偏向于客观性而设计则侧重主观性（当然它们是相辅相成的）。 这样子一来做设计带给我的是太多的选择性， 自然也就带来更多的不确定性。

        并未完全满足于任何过往的任何一天， 继续寻找使新一天更有意义的生活方式。 加油！

 

2、 今天开始构造 邮件系统。 先将自己的设计思乡及其中的困难做一个记录  （8月13日）

       ————数据库表的设计

--------邮件系统的实现------

--1、
x_message(     --信箱表
receiver_name varchar2--收件人名字（唯一）
sender_name   varchar2--发送人名字(唯一)
mes_title   varchar2   --消息标题
mes_content  varchar2  --消息内容
mes_time       date    --发送时间
mes_direction  number  --发送方向 0代表发消息，  1代表接收消息
mes_resource   number  --消息来源 0代表 系统消息， 1代表好友消息， 2代表陌生人消息
mes_select    number   --消息是否被选中 0代表选中  1代表未选 （用于删除）

)

--2、
x_email(   --邮件群发表 （后台）
manager_name   varchar2  --管理员名字（唯一）
receiver_email  varchar2  --根据注册用户email发送邮件 （用户通过邮件激活）
user_level   number  --在下拉框中列出所有的级别， 选择某一级别
send_type   number  --发送类别 0代表 发送给个人 1代表发送给某一级别的用户 2代表发给全体用户
send_time  date    --发送时间
email_select number  --是否被选中 （用于删除）
send_direction number --发送方向 0代表发送到站内 1代表发送到站外
email_title  varchar2  --邮件标题
email_content  类型待定 --邮件内容 （向站外发送email时支持附件、图片等）
)

   设计思想：

  A、 前台： 用户可以向外发邮件但接收外战的邮件， 而且用户向外发的邮件不被系统保存， 所以设计数据库表时只考虑用户发站内消息的情况。

          其中在收件箱对信件进行了分类，分成站内好友、陌生人、系统消息三类。关于mes_direction字段是用于查询的， 因为只有设计了这个标记值才方便进行分类查询... 

B、 后台：

        后台只提供发送邮件的功能， 发送对象分为三类： 某个特定的用户（如每个用户在注册时发送一个连接给注册用户，让用户通过点击链接来激活账号或给某个具体的用户生日祝贺等）； 某个特定级别的所有用户（如给所有新手级别发送一封邮件）； 给站内全体用户发送邮件。

          ——————疑问——————

    a、 后台群发邮件是否要保存（关系到是否要建x_email表）？

    b、 还有一种情况是系统发送的，系统发送的电子邮件在比较密集的情况下，比如向所有的客户群发一封新年贺信，因为电子邮件服务器都比较慢，而且不可靠，通常会把要发的邮件推送到一个数据表，叫做待发邮件表，后台跑一个异步服务，从待发邮件表里面检索要发的邮件通过SMTP发送出去，成功发送后记录转移到已发邮件表，不成功的时候，可能会再尝试几次还不成功就把记录转移到失败邮件表。
数据库的待发邮件表实际上充当了异步服务的消息队列...

            作为一个视频网站来说是否有必要这么做？

           当然， 现在还没有考虑实现的问题...  ...  加油！   ——睡觉去了...

 

——————8月14日——————————

  首先对昨晚的数据库设计做了修改， 修改情况如下：

 --邮箱系统
--15. 信箱表 (x_email)
create table x_single_email(
email_id number(5) primary key,--邮件id
receiver_id number --收件人ID
sender_id   number  --发件人ID
receiver_name varchar2(100),--收件人名字（唯一）
sender_name   varchar2(100),--发送人名字(唯一)
email_title   varchar2(100)   --消息标题
email_content  varchar2(500)  --消息内容
email_time       date,  --发送时间
email_resource   number, --消息来源 0代表 系统消息， 1代表好友消息， 2代表陌生人消息
)

--16. 邮件群发表(x_mass_email) （后台）
create table x_mass_email(
mm_id number(5) primary  key, --群发邮件id
manager_id  number,
manager_name   varchar2, --管理员名字（唯一）
receiver_email  varchar2, --根据注册用户email发送邮件 （用户通过邮件激活）
user_level_id   varchar2,--在复选框列出所有的级别， 选择某一级别,有多个以","分隔
send_type   number,  --发送类别 0代表 发送给个人  1代表发给群体用户
send_time  date,  --发送时间
send_direction number, --发送方向 0代表发送到站内 1代表发送到站外
email_title  varchar2, --邮件标题
email_content ,--邮件内容 （向站外发送email时支持附件、图片等）
fj_address varchar2  --附件地址
user_id  number  --用于关联用户表  （后来添加）
)
--25. 邮件附件表(x_email_fj)
create table x_email_fj(
accessory_id number(5) primary key,--附件id，主键increment生成
mm_id  number,--emial id  外键
accessory_name varchar2(200),--附件名
accessory_address varchar2(500)--附件保存路径
)

   花了一个晚上将今天白天项目组讨论的数据库设计文档给整理好了。  这项工作很考验耐心， 我一定要专业的态度来做好这个项目。 明天开始构造界面........

 

————————————————痛苦波折   8月17日————————————————

    今天已是17号了， 为了自己那个木块的界面我整整郁闷了三天。 中级项目的时候由于自己做的是整个后台， 我从网上copy了一个模板即用倒也不曾发现什么问题， 但是这次这个界面由于在网上没能找到适合的模板...  ....    

    第一天， 只是感觉被压力压得喘不过气来但是实际的工作又没能有什么进展， 唯一地收获便是硬盘上面多出了几十个网站模板而已。

   第二天总算是有点开窍了， 于是想从参照的视频往上直接查看其页面源代码然后再构造， 运行一下效果很差， 原因在于对于页面中掺杂的很多js/jquery代码理不清个头绪来，忙活了大半天又推到重来。

  第三天， 终于下定决心去学习一下布局方面的知识， 于是在网上找了一套有关CSS+DIV的视频教程看， 一直看到凌晨2点多看完11集。 接下来算是对CSS+DIV有所了解，然而就要自己构造出也是不可能的事情， 幸好有了这些基础再来看源文件就更容易了。 最后也因此而使自己能将页面的源代码全部肢解开来并加以理解， 最终拼凑成了一个“四不像”的网页。

     还好， 炼狱般的3天总算熬出了一点点东西，在此期间觉得自己的情商还得加强， 因为之前我曾有过多次半途放弃的念头。

     在怀疑和犹豫面对面透视我们的时候， 我们的责任呼唤我们勇敢地前行， 从而终会发觉： 真理往往都是在险而远处！

     在次项目期间一定要全力以赴， 不要胡思乱想。 不管年底是进银行或从事市场领域的工作，现在就是做技术， 没有什么比把当下的事情做到机制对个人的成长最有效果！   加油！

 

————————————————————数据库最终修改版————————————————

————————————数据库修改版————————————————————
   觉得 用户昵称  也即 用户名应该不可以修改（即系统不提供修改用户名的功能）。
原版：
      --17. 信箱表 (x_email)
create table x_single_email(
email_id number(5) primary key,--邮件id
receiver_id number, --收件人ID
sender_id   number,  --发件人ID
receiver_name varchar2(100),--收件人名字（唯一）
sender_name   varchar2(100),--发送人名字(唯一)
email_title   varchar2(100),   --消息标题
email_content  varchar2(500),  --消息内容
email_time       date,  --发送时间
email_resource   number, --消息来源 0代表 系统消息， 1代表好友消息， 2代表陌生人消息
constraint email_receive_fk foreign key(receiver_id) references x_user(userid),
constraint email_send_fk foreign key(sender_id) references x_user(userid)
)

修改成：

pure_news( --纯粹的信息表
email_id number(5) primary key,--邮件id
email_title   varchar2(100),   --消息标题
email_content  varchar2(500),  --消息内容
email_time       date,  --发送时间

)

relation_email(
relation_id number(5) primary key, --关系id
receiver_id number, --收件人ID
sender_id   number,  --发件人ID
receiver_name varchar2(100),--收件人名字（唯一）
sender_name   varchar2(100),--发送人名字(唯一)
email_resource   number, --消息来源 0代表 系统消息， 1代表好友消息， 2代表陌生人消息
read_status number  --阅读状态（0--未读， 1--已读）
)

  因为之前那样子将所有站内信的东东都存放在一个表中， 那么没有任何用户可以删除信件啦， 因为一旦删除那么则删除了整个相同的信件（这样子对于群发站内信是不可行的）。