精华内容
下载资源
问答
  • 站内信

    2018-01-23 19:41:48
    网站站内信设计 针对网站: 用户数量中等(少于w) 针对场景: 一对一 一对多 数据库设计: 分为两张表,一张表为message,一张表为群发GroupMessage Message: 字段 备注 id 主键 senderId ...

    java web 站内信

    网站站内信设计

    • 针对网站:
      用户数量中等(少于w)
    • 针对场景:
      一对一
      一对多

    • 数据库设计:
      分为两张表,一张表为message,一张表为群发GroupMessage

      • Message:
      字段 备注
      id 主键
      senderId 发送方id
      recId 接收方id
      content 内容
      messageTitle 消息标题
      status 消息状态;0表示未读,1表示已读,2表示删除
      recRoleId 接收方角色,若为空,则表示一对一
      timing 固定时间发送,若为空,则表示非定时
      sendTime 发送时间
      • GroupMessage
      字段 备注
      id 主键
      userId 具体接收方id
      messageId 消息详情id
      messageTitle 消息标题
      groupMessageStatus 个人针对群发消息的状态
    • 逻辑操作:

      • 一对多
        针对发送者:
        创建一条Message数据,recId为空,recRoleId为具体值,timing为空,非定时
        根据Message自动创建一条GroupMessage数据,groupMessageStatus默认为0
        (若定时,则到指定时间再根据Message创建GroupMessage)

        针对接收者:
        接收者登录
        获得GroupMessage表中所有groupMessageStatus为0且userId为该用户id的消息
        获得Message表中所有status为0且userId为该用户id的消息
        此时已获得所有未读消息
        点开群发未读消息,groupMessageStatus置1并保存
        点击删除群发已读消息,groupMessageStatus置2并保存

      • 一对一
        针对发送者:
        创建一条Message数据,recRoleId为空,timing为空,非定时

        针对接收者:
        接收者登录
        获得GroupMessage表中所有groupMessageStatus为0且userId为该用户id的消息(无新消息)
        获得Message表中所有status为0且userId为该用户id的消息
        此时已获得所有未读消息
        点开未读消息,status置1并保存
        点击删除已读消息,status置2并保存

      • 调用表的顺序:
        用户登录 - 查找groupMessage表(获得messageId)- 查找Message表获得message (群信息)- 查找Message表获得message(个人信息)


    第二种设计:

    • 一张表为消息表Message,一张表为消息内容表MessageContent
    • Message

      字段 备注
      id 主键
      senderId 发送者id
      messageId 消息内容id
      recId 接收者id
      status 消息状态
      timing 是否定时(在规定时间将内容显示出来)
    • MessageContent

      字段 备注
      id 主键
      messageContent 消息内容
      messageTitle 消息标题
      date 消息发送时间
    展开全文
  • 现在很多SNS网站和一部分CMS网站都广泛地应用了站内信这一模块,这个看似简单的东西其实背后隐藏着很多需要设计师重视的设计细节,要做好这个“邮递员”是很不容易的。为什么这么说呢?下面我们就一步步来探索设计一...

    随着WEB2.0的发展,用户之间的信息交互也变得十分庞大,而且实时性要求越来越高。现在很多SNS网站和一部分CMS网站都广泛地应用了站内信这一模块,这个看似简单的东西其实背后隐藏着很多需要设计师重视的设计细节,要做好这个“邮递员”是很不容易的。为什么这么说呢?下面我们就一步步来探索设计一个百万级用户量的站内信群发数据库,看完以后你就会明白什么是真正可靠高效的“邮递员”。

    1、几十——几百的用户量

    这样的网站规模最小,可能是一个中小企业的CMS系统,面对这样的用户量,我们就不必要考虑短消息数据量太大的问题了,所以按照怎么方便怎么来的原则,群发就每人复制一条消息数据,这样用户可以自己管理自己的消息,可以非常方便进行“已读、未读、删除”等操作。按照这个思路,我们的数据库设计如下:

    表T_Message

    这样,我们接受自己的消息时只要做如下查询:

    查询自己的未读消息只要做如下查询:

    这种方法很简单,可能是我们第一个想到的,对于这样的用户量的情况这样的设计确实也足够了。

    2、几千——几万的用户量

    用户量到了这样的级哦别,这个网站应该算是比较大了,笔者估计,可能是一个地区性的SNS网站。那么面对这样的用户量,我们又该如何来设计站内信群发呢?上面第一种思路还行得通吗?应该这样说,如果勉强要用上面那种设计,也是可以的,只不过T_Message可能要考虑分区。但是,大家会不会觉得消息正文复制那么多条对于这样的用户量来讲空间浪费太大,因为考虑到接收者一般是不修改消息正文的,所以我们可以让所有接收者共享一条消息正文。具体数据库设计方法和上面大同小异:

    T_Message

    T_MessageText

    这样,我们就大大节省了消息的存储空间,但是查询的时候就稍微麻烦一点,就需要进行联合查询了,查询自己的未读消息可以这样(意思一下,可能还有更高效的查询方式):

    用这种方法除了正文我们不能随便删除外,用户还是可以自己管理自己的消息。

    3、百万级大用户量

    如果一个网站到了百万级的用户量了,那我不得不膜拜该网站和网站经营者了,因为经营这样的网站一直是笔者的梦想:)好了,回归正题,如果这样的系统放你面前,让你设计一个站内信群发数据库,你该何去何从,总之,上面两种常规的办法肯定是行不通了的,因为庞大的数据量会让消息表撑爆,即使你分区也无济于事。这时候作为一个系统架构师的你,可能不仅仅要从技术的角度去考虑这个问题,更要从用户实际情况去着手寻找解决问题的办法。这里,有一个概念叫“活跃用户”,即经常登录网站的用户,相对于那些一时冲动注册而接下来又从来不登录的用户来说,活跃用户对网站的忠诚度很高,从商业的角度来讲,忠诚的客户享受更高端的服务。

    根据这个思路,我们来探索一种方法。假设网站有500万注册用户,其中活跃用户为60万(这个比例真很不错了),现在我们要对所有用户群发一封致谢信。还是上面两张表,首先我们可以先往消息表中插入一条群发标识为-1的消息,这里我们用字段SourceMessageId(原始消息)来标识(-1为原始群发消息本身,其他则是原始消息id),这样其实群发的工作已经完成了,用户可以看到这条公共的消息了。但是用户需要有消息的控制权,所以必须让每个用户拥有一条自己的消息。要达到这个目的,我们可以让用户登录时检查是否已经拷贝原始消息,如果没有拷贝,则拷贝一份原始消息并插入消息表,群发标识为原始消息的id;如果已经存在原始消息的拷贝,则什么都不做。这样,我们就只要为这60万活跃用户消耗消息空间就可以了。具体数据库设计如下:

    T_Message

    表T_MessageText与上面方法的一样。

    当然,如果你的活跃用户达到100%,那这种方法相对前一种就没有优势了,但这种情况基本上不太可能,所以,笔者觉得这种方法来处理大用户量的消息群发还是可行的。

    4、总结

    本文只是大致阐述了实现的原理,很多细节都忽略没有考虑,纯粹一个设计想法而已,有兴趣的朋友可以去自己实践一下,另外,笔者对数据库也不是很精通,如果有哪里阐述错误的还请指出,让我们一起进步。

    5、如果你喜欢设计和架构,你可能还会喜欢以下文章

    展开全文
  • 现在很多SNS网站和一部分CMS网站都广泛地应用了站内信这一模块,这个看似简单的东西其实背后隐藏着很多需要设计师重视的设计细节,要做好这个“邮递员”是很不容易的。为什么这么说呢?下面我们就一步步来探索设计一...

    随着WEB2.0的发展,用户之间的信息交互也变得十分庞大,而且实时性要求越来越高。现在很多SNS网站和一部分CMS网站都广泛地应用了站内信这一模块,这个看似简单的东西其实背后隐藏着很多需要设计师重视的设计细节,要做好这个“邮递员”是很不容易的。为什么这么说呢?下面我们就一步步来探索设计一个百万级用户量的站内信群发数据库,看完以后你就会明白什么是真正可靠高效的“邮递员”。

    1、几十——几百的用户量

    这样的网站规模最小,可能是一个中小企业的CMS系统,面对这样的用户量,我们就不必要考虑短消息数据量太大的问题了,所以按照怎么方便怎么来的原则,群发就每人复制一条消息数据,这样用户可以自己管理自己的消息,可以非常方便进行“已读、未读、删除”等操作。按照这个思路,我们的数据库设计如下:

    表T_Message

    1
    2
    3
    4
    5
    6
    Id            bigint      --消息ID
    SenderId      bigint      --发送者ID
    ReceiverId    bigint      --接收者ID
    SendTime      datetime    --发送时间
    ReadFlag      tinyint     --已读标志
    MessageText   text        --消息正文

    这样,我们接受自己的消息时只要做如下查询:

    1
    SELECT * FROM T_Message WHERE ReceiverId=myid

    查询自己的未读消息只要做如下查询:

    1
    SELECT * FROM T_Message WHERE ReceiverId=myid and ReadFlag=0

    这种方法很简单,可能是我们第一个想到的,对于这样的用户量的情况这样的设计确实也足够了。

     

    2、几千——几万的用户量

    用户量到了这样的级哦别,这个网站应该算是比较大了,笔者估计,可能是一个地区性的SNS网站。那么面对这样的用户量,我们又该如何来设计站内信群发呢?上面第一种思路还行得通吗?应该这样说,如果勉强要用上面那种设计,也是可以的,只不过T_Message可能要考虑分区。但是,大家会不会觉得消息正文复制那么多条对于这样的用户量来讲空间浪费太大,因为考虑到接收者一般是不修改消息正文的,所以我们可以让所有接收者共享一条消息正文。具体数据库设计方法和上面大同小异:

    T_Message

    1
    2
    3
    4
    5
    6
    Id              bigint      --消息ID
    SenderId        bigint      --发送者ID
    ReceiverId      bigint      --接收者ID
    SendTime        datetime    --发送时间
    ReadFlag        tinyint     --已读标志
    MessageTextId   bigint      --这里把消息正文内容换成消息正文Id

    T_MessageText

     

     

    1
    2
    3
    Id              bigint      --ID标识
    SenderId        bigint      --发送者ID
    MessageText     text        --消息正文

    这样,我们就大大节省了消息的存储空间,但是查询的时候就稍微麻烦一点,就需要进行联合查询了,查询自己的未读消息可以这样(意思一下,可能还有更高效的查询方式):

    1
    2
    3
    SELECT T_Message.*,T_MessageText.* FROM T_Message
    INNER JOIN T_MessageText ON T_Message.MessageTextId=T_MessageText.Id
    WHERE T_Message.ReceiverId=myid AND T_Message.ReadFlag=0

    用这种方法除了正文我们不能随便删除外,用户还是可以自己管理自己的消息。

     

    3、百万级大用户量

    如果一个网站到了百万级的用户量了,那我不得不膜拜该网站和网站经营者了,因为经营这样的网站一直是笔者的梦想:)好了,回归正题,如果这样的系统放你面前,让你设计一个站内信群发数据库,你该何去何从,总之,上面两种常规的办法肯定是行不通了的,因为庞大的数据量会让消息表撑爆,即使你分区也无济于事。这时候作为一个系统架构师的你,可能不仅仅要从技术的角度去考虑这个问题,更要从用户实际情况去着手寻找解决问题的办法。这里,有一个概念叫“活跃用户”,即经常登录网站的用户,相对于那些一时冲动注册而接下来又从来不登录的用户来说,活跃用户对网站的忠诚度很高,从商业的角度来讲,忠诚的客户享受更高端的服务。

    根据这个思路,我们来探索一种方法。假设网站有500万注册用户,其中活跃用户为60万(这个比例真很不错了),现在我们要对所有用户群发一封致谢信。还是上面两张表,首先我们可以先往消息表中插入一条群发标识为-1的消息,这里我们用字段SourceMessageId(原始消息)来标识(-1为原始群发消息本身,其他则是原始消息id),这样其实群发的工作已经完成了,用户可以看到这条公共的消息了。但是用户需要有消息的控制权,所以必须让每个用户拥有一条自己的消息。要达到这个目的,我们可以让用户登录时检查是否已经拷贝原始消息,如果没有拷贝,则拷贝一份原始消息并插入消息表,群发标识为原始消息的id;如果已经存在原始消息的拷贝,则什么都不做。这样,我们就只要为这60万活跃用户消耗消息空间就可以了。具体数据库设计如下:

    T_Message

    1
    2
    3
    4
    5
    6
    7
    Id                  bigint      --消息ID
    SenderId            bigint      --发送者ID
    ReceiverId          bigint      --接收者ID,如果为原始群发消息则为-1
    SendTime            datetime    --发送时间
    ReadFlag            tinyint     --已读标志,如果为原始群发消息则统一为0未读
    SourceMessageId     bigint      --如果为-1则为原始群发消息,其他则为原始消息id
    MessageTextId       bigint      --这里把消息正文内容换成消息正文Id

    T_MessageText与上面方法的一样。

     

    当然,如果你的活跃用户达到100%,那这种方法相对前一种就没有优势了,但这种情况基本上不太可能,所以,笔者觉得这种方法来处理大用户量的消息群发还是可行的。

     

    4、总结

    本文只是大致阐述了实现的原理,很多细节都忽略没有考虑,纯粹一个设计想法而已,有兴趣的朋友可以去自己实践一下,另外,笔者对数据库也不是很精通,如果有哪里阐述错误的还请指出,让我们一起进步。

    转载于:https://www.cnblogs.com/ywsoftware/archive/2013/02/22/2922033.html

    展开全文
  • 现在很多SNS网站和一部分CMS网站都广泛地应用了站内信 这一模块,这个看似简单的东西其实背后隐藏着很多需要设计师重视的设计细节,要做好这个“邮递员”是很不容易的。为什么这么说呢?下面我们就一步步来探索 ...

    随着WEB2.0的发展,用户之间的信息交互也变得十分庞大,而且实时性要求越来越高。现在很多SNS网站和一部分CMS网站都广泛地应用了站内信 这一模块,这个看似简单的东西其实背后隐藏着很多需要设计师重视的设计细节,要做好这个“邮递员”是很不容易的。为什么这么说呢?下面我们就一步步来探索 设计一个百万级用户量的站内信群发 数据库,看完以后你就会明白什么是真正可靠高效的“邮递员”。

    1、几十——几百的用户量

    这样的网站规模最小,可能是一个中小企业的CMS系统,面对这样的用户量,我们就不必要考虑短消息数据量太大的问题了,所以按照怎么方便怎么来的原 则,群发就每人复制一条消息数据,这样用户可以自己管理自己的消息,可以非常方便进行“已读、未读、删除”等操作。按照这个思路,我们的数据库设计如下:

    表T_Message

    1
    2
    3
    4
    5
    6
    Id            bigint       --消息ID
    SenderId      bigint       --发送者ID
    ReceiverId    bigint       --接收者ID
    SendTime      datetime    --发送时间
    ReadFlag      tinyint     --已读标志
    MessageText   text        --消息正文

    这样,我们接受自己的消息时只要做如下查询:

    1
    SELECT * FROM T_Message WHERE ReceiverId=myid

    查询自己的未读消息只要做如下查询:

    1
    SELECT * FROM T_Message WHERE ReceiverId=myid and ReadFlag=0

    这种方法很简单,可能是我们第一个想到的,对于这样的用户量的情况这样的设计确实也足够了。

     

    2、几千——几万的用户量

    用户量到了这样的级哦别,这个网站应该算是比较大了,笔者估计,可能是一个地区性的SNS网站。那么面对这样的用户量,我们又该如何来设计站内信群 发呢?上面第一种思路还行得通吗?应该这样说,如果勉强要用上面那种设计,也是可以的,只不过T_Message可能要考虑分区。但是,大家会不会觉得消 息正文复制那么多条对于这样的用户量来讲空间浪费太大,因为考虑到接收者一般是不修改消息正文的,所以我们可以让所有接收者共享一条消息正文。具体数据库 设计方法和上面大同小异:

    T_Message

    1
    2
    3
    4
    5
    6
    Id              bigint       --消息ID
    SenderId        bigint       --发送者ID
    ReceiverId      bigint       --接收者ID
    SendTime        datetime    --发送时间
    ReadFlag        tinyint     --已读标志
    MessageTextId   bigint       --这里把消息正文内容换成消息正文Id

    T_MessageText

    1
    2
    3
    Id              bigint       --ID标识
    SenderId        bigint       --发送者ID
    MessageText     text        --消息正文

    这样,我们就大大节省了消息的存储空间,但是查询的时候就稍微麻烦一点,就需要进行联合查询了,查询自己的未读消息可以这样(意思一下,可能还有更高效的查询方式):

    1
    2
    3
    SELECT T_Message.*,T_MessageText.* FROM T_Message
    INNER JOIN T_MessageText ON T_Message.MessageTextId=T_MessageText.Id
    WHERE T_Message.ReceiverId=myid AND T_Message.ReadFlag=0

    用这种方法除了正文我们不能随便删除外,用户还是可以自己管理自己的消息。

     

    3、百万级大用户量

    如果一个网站到了百万级的用户量了,那我不得不膜拜该网站和网站经营者了,因为经营这样的网站一直是笔者的梦想:)好了,回归正题,如果这样的系统 放你面前,让你设计一个站内信群发数据库,你该何去何从,总之,上面两种常规的办法肯定是行不通了的,因为庞大的数据量会让消息表撑爆,即使你分区也无济 于事。这时候作为一个系统架构师的你,可能不仅仅要从技术的角度去考虑这个问题,更要从用户实际情况去着手寻找解决问题的办法。这里,有一个概念叫“活跃 用户”,即经常登录网站的用户,相对于那些一时冲动注册而接下来又从来不登录的用户来说,活跃用户对网站的忠诚度很高,从商业的角度来讲,忠诚的客户享受 更高端的服务。

    根据这个思路,我们来探索一种方法。假设网站有500万注册用户,其中活跃用户为60万(这个比例真很不错了),现在我们要对所有用户群发一封致谢信。还是上面两张表,首先我们可以先往消息表中插入一条群发标识为-1 的 消息,这里我们用字段SourceMessageId(原始消息)来标识(-1为原始群发消息本身,其他则是原始消息id),这样其实群发的工作已经完成 了,用户可以看到这条公共的消息了。但是用户需要有消息的控制权,所以必须让每个用户拥有一条自己的消息。要达到这个目的,我们可以让用户登录时检查是否 已经拷贝原始消息,如果没有拷贝,则拷贝一份原始消息并插入消息表,群发标识为原始消息的id ;如果已经存在原始消息的拷贝,则什么都不做。这样,我们就只要为这60万活跃用户消耗消息空间就可以了。具体数据库设计如下:

    T_Message

    1
    2
    3
    4
    5
    6
    7
    Id                  bigint       --消息ID
    SenderId            bigint       --发送者ID
    ReceiverId          bigint       --接收者ID,如果为原始群发消息则为-1
    SendTime            datetime    --发送时间
    ReadFlag            tinyint     --已读标志,如果为原始群发消息则统一为0未读
    SourceMessageId     bigint       --如果为-1则为原始群发消息,其他则为原始消息id
    MessageTextId       bigint       --这里把消息正文内容换成消息正文Id

    T_MessageText 与上面方法的一样。

    当然,如果你的活跃用户达到100%,那这种方法相对前一种就没有优势了,但这种情况基本上不太可能,所以,笔者觉得这种方法来处理大用户量的消息群发还是可行的。

     

    4、总结

    本文只是大致阐述了实现的原理,很多细节都忽略没有考虑,纯粹一个设计想法而已,有兴趣的朋友可以去自己实践一下,另外,笔者对数据库也不是很精通,如果有哪里阐述错误的还请指出,让我们一起进步。

     

    5、如果你喜欢设计和架构,你可能还会喜欢以下文章

    Facebook和人人网的网站后台架构对比

    facebook图片存储架构技术全解析

    各大网站架构总结笔记

    一步步构建大型网站架构

    大型网站架构不得不考虑的10个问题

     

    本文为笔者原创,欢迎转载,但请在页面明显处表明原文链接,谢谢!
    原文链接:http://www.itivy.com/ivy/archive/2011/6/3/sms-db-design-of-million-user.html

    展开全文
  • 本系统带文档lw1万字+答辩PPT+查重 如果这个题目不合适,可以去我上传的资源里面找题目,找不到的话,评论留下题目,或者站内我, 有时间看到机会给你发 系统用例分析 1管理员用例图 系统中的核心用户是系统...
  • web安问全题

    2021-01-09 16:34:38
    免费的WiFi,欢迎页,偷偷请求好多网站,访问A时,加载了b的通用脚本jq/bs(内含恶意脚本),由于大部分网站有缓存静态文件(jq,bootstrap)的时间较长。离开免费WiFi后,再次请求A时候,就会触发jq中含有的恶意...
  • 类似QQ空间人人网站的设计

    热门讨论 2012-09-19 17:39:47
    java web开发应用.类似人人空间的设计,比较简单,有说说,日志,相册,站内信,留言,互相访问等功能.登录页面设计类似人人网,数据库采用Oracle.
  • - 站内信 模块 (Messages) (功能:发送站内信、删除站内信,回复站内信) - 图片相册 模块 (Albums) (功能:创建相册、编辑相册、删除相册、上传图片、编辑图片、删除图片) - 博客 模块 (Blogs) (功能:创建博客、...
  • - 站内信 模块 (Messages) (功能:发送站内信、删除站内信,回复站内信) - 图片相册 模块 (Albums) (功能:创建相册、编辑相册、删除相册、上传图片、编辑图片、删除图片) - 博客 模块 (Blogs) (功能:创建博客、...
  • 生成HTML、URLRewrite、标签缓存、SQL缓存、页面缓存、远程附件、计划任务、数据库备份恢复、VIP会员、企业主页、二级域名、主页模板、在线充值、资金提现、产品交易、站内信、询盘、报价、关键字排名、商机收藏、...
  • Destoon B2B网站管理系统是一套完善的B2B(电子...板、在线充值、资金提现、产品交易、站内信、询盘、报价、关键字排名、商机收藏、邮件订阅、邮件群发、客服中心、会员整合、广告管理、友情链接、单网页、 RSS订阅...
  • 此外还完成了会员开店,个人商品管理,站内信等功能.. (正在继续完善中...) 希望本系统对初学者了解asp.Net 有所帮助.. 同时也希望有兴趣的朋友加入我们的团队来.一起参与 拍宝网的开发. 相信这是一个学习...
  • 本书从建的准备工作开始,写到建立功能强大的INTERNET网站,层层深入,涉及到网站建设中所遇到的种种问题。从Linux的安装和设置入手,详尽地介绍了如何建立普通站点及具有WWW、E-MAIL、FTP、BBS等功能的完整的...
  • 生成HTML、URLRewrite、标签缓存、SQL缓存、页面缓存、远程附件、计划任务、数据库备份恢复、VIP会员、企业主页、二级域名、主页模 板、在线充值、资金提现、产品交易、站内信、询盘、报价、关键字排名、商机收藏、...
  • 生成HTML、URLRewrite、标签缓存、SQL缓存、页面缓存、远程附件、计划任务、数据库备份恢复、VIP会员、企业主页、二级域名、主页模 板、在线充值、资金提现、产品交易、站内信、询盘、报价、关键字排名、商机收藏、...
  • 本书从建的准备工作开始,写到建立功能强大的Internet网站,层层深入,涉及到网站建设中所遇到的种种问题。从Linux的安装和设置入手,详尽地介绍了如何建立普通站点及具有WWW、E-mail、FTP、BBS等功能的完整的...
  • 使用dwr实现后台消息推送功能

    千次阅读 热门讨论 2013-10-26 18:24:24
    大多数网站都有站内信,未读消息,今日要闻等消息的推送功能,就拿本站来说打开今日第一次csdn首页,立马会在右下角出现一个弹出窗口,就是下图这样的,你一定见过的: 很多无良网站都会有各种各样的浮动层,飘来飘...
  • 本系统带文档lw万字以上+答辩PPT+查重 如果这个题目不合适,可以去我上传的资源里面找题目,找不到的话,评论留下题目,或者站内我, 有时间看到机会给您发 电子班牌系统网站设计基于Web服务模式,是一个适用...
  • 本系统带文档lw万字以上+答辩PPT+查重 如果这个题目不合适,可以去我上传的资源里面找题目,找不到的话,评论留下题目,或者站内我, 有时间看到机会给您发 电子班牌系统网站设计基于Web服务模式,是一个适用于...
  • 直到我在CSDN站内看到了一件真事儿:一位博主贴出了自己10分钟用Python搭建小说网站的全过程!全程只用了2步操作,简直太秀了!!……第一步:爬取小说数据库第二步:用Python的热门框架Django直接做Web实现!在这篇...
  • 本系统带文档lw万字以上+答辩PPT+查重 如果这个题目不合适,可以去我上传的资源里面找题目,找不到的话,评论留下题目,或者站内我, 有时间看到机会给您发 社团事务管理系统 基于Web服务模式,是一个适用于...
  • 2. 通过手机客户端,网站用户不仅可以浏览帖子、发帖、回帖、收发站内信等基本的社区操作;还能体验新闻快报及社区互动,更能享受拍照上传、定位交友、微博共享等移动专属服务。 1. 网站可以享受自定义桌面图标、...
  • 再谈Cocoon兼谈JSP

    2004-11-20 09:09:00
    选择自 hax 的 Blog 发信人: HAX(海曦), 区: WebDevelop标 题: 再谈Cocoon兼谈JSP发信站: 饮水思源 (2002年06月06日01:17:17 星期四), 站内信件著名的 IBM DW 中文网站,推出了Cocoon 2的简介教程,从而再次把...
  • 本系统带文档lw万字以上+答辩PPT+查重 如果这个题目不合适,可以去我上传的资源里面找题目,找不到的话,评论留下题目,或者站内我, 有时间看到机会给您发 社团事务管理系统 基于Web服务模式,是一个适用于...
  • 本系统带文档lw万字以上+答辩PPT+查重 如果这个题目不合适,可以去我上传的资源里面找题目,找不到的话,评论留下题目,或者站内我, 有时间看到机会给您发 概述 网上拍卖系统基于Web服务模式,是一个适用于...

空空如也

空空如也

1 2 3
收藏数 59
精华内容 23
关键字:

web网站站内信