框架
site -> channel -> block -> item

共含 n 个站点(主要是预留给各个虚拟主机),

每个站点含 n 个频道,

每个频道 含\uFFFD\uFFFDn\uFFFD\uFFFD个 栏目,且每个栏目还可以含 n 个子栏目,多层,

每个栏目 含 n 个 主体内容(主要是文章、帖子)。


这就是我正在实施的新网站框架,欢迎大家发表高见。


------

回复此文章 |

宏伟计划,抛砖先,请hofman不要取笑。
site:main,recruit,ftp,vod,mail,blog,bbs,game……
main充当门户作用和存放一些静态页面,recruit招生专用包括学生管理数据库,ftp文档下载目前不重要,vod教学录像点播顺便看原版电影听听歌曲和英语听力应该是互动教学的空间,mailblogbbs通用,game架设自己的服务器确定校内高手排行,还需要什么?
------

回复此文章 |

好的!
我们可以有自己的独立域名吗?
空间可以给点吗
------

回复此文章 |

我们大学的各个二级学院是不是自己有网站!
有的话,可以给他们做个链接什么的!
如果没有,我建议还是给他们留一个框架啊。
我认为这样能壮大我们的网站!
------
回复此文章 |
回复主题:Re:Re:Re:Re:大家对框架发表意见吧 | 作者: haohao | 军衔:六级军士 | 发表时间:2004-04-09 10:55:22
我们是不是可以给学生会留个地方呀
------

回复此文章 |

对啊,我们也可以凑凑热闹啊!

------

回复此文章 |

大家没有注意吗,我一开始就说明了,有4级以上层次,就是给学生的独立域名、独立空间预留的。

这是我比较得意的地方呢,并行多个网站,独立又统一。


coffee意见很好,不过,眼下还是把本院网站做好,大约7月的样子,可能才有精力作

game之类的东西。

------

回复此文章 |
--------------- 引用-----------------
site -> channel -> block -> item

共含 n 个站点(主要是预留给各个虚拟主机),

每个站点含 n 个频道,

每个频道 含\uFFFD\uFFFDn\uFFFD\uFFFD个 栏目,且每个栏目还可以含 n 个子栏目,多层,

每个栏目 含 n 个 主体内容(主要是文章、帖子)。
-------------------------------------
hofman的意思是这样吧?
[-]http://www.zhuoda.org/
[-]|-web-->|
|site1--->|
|------[-]|channel1-->|
| |-[-]|block-->|
| | |ITEM1
| | |ITEM2
| | |ITEM...
| | |ITEM[n]
| |-[+]|block2
| |-[+]|block...
| |-[+]|block[n]
|------[+]channel2
|------[+]channel...
|------[+]channel[n]
[+]|site2
[+]|.....
[+]|site[n]
-----------------------------------------------------------
优点:目录清晰,便于浏览
缺点:管理起来较为麻烦,而且每个分之都建立在一个主的文件夹下,查找起来也很麻烦.
我建议作如下改动:
----------------------------------------------------------
每个分之单用一个文件夹,并写代码记载每个文件的具体名称,载入日hannels
| |-[+]_note
| |-[+]channel1
| |-[+]channel...
| |-[+]channel[n]
|-[-]blocks
| |-[+]_note
| |-[+]block1
| |-[+]block...
| |-[+]block[n]
|-[-]ITEMS
| |-[+]_note
| |-[+]ITEM1
| |-[+]ITEM...
|______|-[+]ITEM[n]
-----------------------------------------------------------------
如此一来,虽然在网站建立的时候看起来很麻烦,但是一旦它成功运转,它的传输效率比起hofman的方案会更高,而且一旦在某个单元出错,可以及时到该单元中去修正,管理起来更加方便.
-----------------------------------------------------------------
示例:
假设第n站点的第n频道的第n个item有损坏,丢失了数据.
如果用先前hofman的方法查询,在开始的几个站点来说会很简单,但是一旦日久天长,会发现目录树层出不穷,在满屏幕的文件夹海洋中搜索一个文件,简直好比大海捞针.
但是我的这个方案就解决起来很容易.使用查询命令,直接在items中文件夹中查询出错的名称,或者日后自行手动寻找,相信都要比前一个方案要方便的多.
hofman您认为呢?
------
有人这么形容我:
猛的一看到你,我吐了……
我仔细的一看……天啊,还不如猛的一看……
-_-b
回复此文章 |
回复主题:Re:Re:大家对框架发表意见吧 | 作者:hofman | 军衔:上尉 | 发表时间:2004-04-09 15:59:54

很好的帖子,很好的建议,谢谢。

你对我的设计的理解是非常正确的,优点、缺点也说得很到位。

你的设计,后天管理似乎是方便一些了,但是更为重要的前台显示,解决起来,好像更麻烦吧。

我们网站是建立在关系数据库(oracle)基础上的,
而不是简单的文件型网站。


我的设计走的是通用的路子,用数据库实现树型目录结构,并非我的独创。

对你的建议,我还要再思考。


------

回复此文章 |

我想知道hofman会怎么选择:

如果可以的话,牺牲一些速度是很有必要的:

我们每个文件夹中的内容,用一个表。并在WEB文件夹中存放数据库,用编程的方法制作每个分支的链表……具体的我也说不好……
您到QQ的论坛上看看吧!有介绍的。
只要便于管理,而且新站的功能健全,我想即使牺牲一些速度,还是会有N多支持者的。
建议您想一下……

给您推荐个网站,我的一个国外的朋友(ICQ认识的)在这个游戏公司工作。这个站虽然慢,但是每天流量决不会低:
http://www.squaresoft.com


hofman   2005-11-19 22:40:03 评论:0   阅读:915   引用:0

发表评论>>

署名发表(评论可管理,不必输入下面的姓名)

姓名:

主题:

内容: 最少15个,最长1000个字符

验证码: (如不清楚,请刷新)

Copyright@2004-2010 powered by YuLog