CMS漂流

虽然总和一般规模的站点打交道，但需求总是千变万化的，当前某个客户的数据库已经达到数千万条记录（10M条规模），虽然离大规模数据处理（G条记录）还差了老远，但已经可以勉强在实际项目中看到点这样的感觉了。
前台访问量没有上来，因此当前的索引状况应付前端访问并无问题，所谓分表、分库现在也完全没用上。
主要的问题在于数据插入，客户需要每次提交一个csv文本，约一万至数万条记录，而.NET组的同事在处理这些记录时，采用的方案是按某字段验证是否存在，若不存在则插入。此字段当然已经有了索引。
但最后的结果是过万条记录至少需要一刻钟时间来处理这些数据，客户认为这个时长不可接受。
因为以前有处理过数百万条记录的经验，因此被抓去给方案。
三种方案：
1. 用户提交数据后，数据进入任务队列，即用户不用盯着浏览器观查页面刷新什么的，关闭浏览器亦可行，这是最基本的。
2.提交的数据先行去重，然后一并放到库里查重，然后使用单一事务一次性插入。
3.若库里面仅以单一字段验证是否重复的话，直接在库里面将此字段设为唯一索引，然后insert插入，返回错误值的则为重复，不重复的则能正常插入。
最后结果，同时采用2和3，在远低于服务器配置的普通PC测试环境下，一万条数据插入可以在1XX秒搞定。

kolidon于 2008年10月
目前常用的WEB应用平台有PHP/ASP.NET(C# and VB.NET)/Java/Perl, Python and Ruby
根据wikipedia.org资料（词条Web_content_management_system）、Google趋势分析、每年举办的全球开源CMS评比及本公司相关专业WEB开发人员反馈，计有如下开源产品受到较多关注：
windows+.NET Framework平台，IIS+ASP.NET（不建议运行于Linux的mono平台）
* DotNetNuke （请参照其官方站点dotnetnuke功能http://www.dotnetnuke.com ）
* mojoPortal
* dotCMS
* Umbraco
windows/linux平台，IIS/APACHE/LIGHTTPD/NGINX + PHP
* Drupal (请参照其官方站及中文站http://drupal.org及http://drupalchina.org )
* Joomla! (请参照http://joomla.org及http://maycode.com及http://www.joomlart.com )
* XOOPS
* ImpressCMS
windows/linux平台，python语言+zope应用服务器
* Plone
我们最终选出Dotnetnuke、Joomla及Drupal用于在不同环境下使用。理由为：这三个应用有足够的成熟度、众多的原生功能/第三方组件与模块支持，较好的可扩展性及普适性。能适用于从小型内容展示站到需求复杂多变的网站群构建，重要的是，这三者在中国大陆地区的普及程度及社区大小均相对强大，这有利于吸引更多爱好者和专业开发人士，使开发工作可以持续延续和深入。
我们并不打算完全重新构造在企业门户站点或网站群中的一些基础的功能应用，例如文章展示、评论、图库系统、用户系统、多媒体展示系统、商城和购物车、论坛、留言和咨询、投票统计与调查、广告、邮件列表、表单、社区功能等等，我们不建议选用Microsoft ASP.NET MVC、及ZEND FRAMEWORK、CakePHP等纯框架产品，因为这与我们快速开发WEB应用及利用既有应用的目标相违背。当然，我们更不建议脱离参照而完全独立设计构造用于企业的门户网站和内容管理系统。
有足够技术实力及相应需求、预算充足的用户，可考虑选用基于python语言的应用服务器zope，或基于IBM WEBSPHERE应用服务器进行JAVA开发，或在Microsoft SHAREPOINT PORTAL SERVER基础上进行开发，前者有较好的社群支持，后两者商业支持足够可靠。
综述，针对企业内联站点及外部门户、网站群的需求，Drupal/Joomla/Dotnetnuke完全能够满足需求，初中高各级程序人员/制作者/设计者，即可按需订制扩展实现功能，快速制作模块、模板，自由实现任何所需效果。
而作为开发框架，其代码复杂程度亦可使普通中、高级程序员得以深入系统核心，由此而借框架之便且能不受限于框架本身，在此基础上开发出完全不同于传统应用的功能如SNS、Web Service应用等。
（请跟踪此链接获得第三方比较报告http://www.digitalartsonline.co.uk/news/index.cfm?NewsID=8854）
基本术语或特性（kolidon制表）

 

Drupal6.x

Joomla1.5.x

dotnetnuke

完成功能

模块

组件

模块

页面外观

模板theme

模板template

模板theme

外观辅助

区域＋容器（包装模块）

位置（包装模块）

区域

节点

节点（文章、博客、书）

 
 

插件或其他辅助

钩子hook（模块相关）

插件plug-in

Provider、component

页面各组成部分

区块，稍弱

组件主体＋模块，强大

模块，稍弱

页面

建页面放置区块和模块

新建菜单，模块菜单对应

建页面，模块与页面对应

扩展安装

手工（FTP上传）

半自动，自动(1.6功能)

半自动（管理界面上传）

缓存系统

有，多级缓存

有，核心开发实现全静态

有，多级缓存

搜索引擎友好

完美

组件，二次开发更完美

完美

数据库

MYSQL，PGSql，可更多

MYSQL，可支持更多

SQLSERVER，可支持更多

开发者友好

好

好

好

用户友好

一般

好

较好

功能比较（kolidon制表）

 

Drupal6.x

Joomla1.5.x

dotnetnuke

权限管理

完善，成员角色分离

完善，前后台均多级

角色系统，成员角色分离

个性化

既有模块

既有组件

未知

群组

既有模块

既有组件

未知

站内信

既有模块

既有组件

未知

其他 SNS功能

组件支持（中）

组件支持（强）

组件支持（？）

应用系统

模块数百种

组件千余种

模块百余种

文章

模块

组件

模块

博客

模块、桥接其他

组件、桥接其他

模块、桥接其他

投票统计

模块

组件

模块

下载

模块

组件

模块

邮件列表

模块

组件

模块

咨询

模块

组件

模块

多媒体

模块

组件

模块

图库

模块

组件

模块

表单

模块

组件

开发

整合其他应用难度

简单

简单

中等

检索系统

检索所有内容

检索所有内容

检索所有内容

网站群

原生支持

安装扩展或简单开发

原生支持

远程控制开发难度

中等

简单，或采既有系统

中等

简评
Drupal:为开发者提供更大自由度和更少依赖。框架简洁但扩展尚算方便，代码完美。目前未见丰富模板；
Joomla:框架优秀，社区支持强。各水平程序员均可参与模块、组件或核心开发。完全释放设计人员灵感；
Dotnetnuke:桥接既有.NET Framework应用方便，模块均为“可用”水准，亦有优秀，功能基本合规。

ASP在IIS上的著名的500服务器内部错误，至今仍让人心有余悸，而重装COM+服务甚至重装IIS似乎从来都是终极解决方案。我们无从得知 ASP.NET与WINDOWS操作系统有多大程度上的耦合，但看看linux下的Mono项目数年来让人心碎的进展就能有结论。而据kolidon实践 经验，ASP.NET的系统稳定性，99%的时候是由对系统欠缺深入研究的管理员的过失——高手群的形成可能尚需时日，现在大家的时间花在了：系统不能对哪些过失自动容错。随着系统的完善，现在的新人们或者能在平心静气三五年后对ASP.NET对WEB应用和革命性诠释，对框架库的企业级规模表示由衷的赞赏。
而现在，license亦是一个大问题，适合中小型应用的优秀开源框架或可作原型的小型应用，绝大多数在同样开源的PHP架构下，比如现在，GPL的wordpress还是我的最爱。
但，discuz!NT横空出世，。
考查WEB应用程序的三个指标：
1. 性能和稳定性；
2. 安全性；
3. UE。
雪人已于2007年底离开comsenz。
由此，
Comsenz在UE上一贯非以出奇致胜，但重在平和，总能大巧若拙——当然，对supesite和xspace这样的产品或者还需要给更多的时间，在phpcms这一类的非社区型平台和drupal这一类的开放接口式平台之间，有亮点的博客定位却未能做强，是为憾事。

baken_cms，原始代码几经磨难，最初的版本和当前的版本之间，有三大风格转变。
1. 纯子文件模块化调用，开发在线文件编辑功能以拼合页面，此版本典型应用在http://www.jingzhui.com；
2. 纯函数式调用及模板化雏形，对常用功能分解为文章、分类、留言、评论、图片、专题等数块，每块有专用函数及参数配置，此版本典型应用在http://www.gupen.com和http://www.zhendao.net；
3. 纯模板化及多用户，侧重编辑流程管理，侧重专业技术人员可操作性。触发生成静态页面并加强统计功能，后台任务系统，此版本曾在http://www.chsa.cn承载了十余万资讯页面量级，惜最后关站。
俱往矣，当下我爱joomla还有dnn。
贴上一段在当时算是创新的代码（asp中的数据库集中操作函数）

性能倒属其次，唯一的好处在于从应用架构上看，所有数据库存取逻辑清晰可控，一叹：干净！
当数据库是瓶颈时，通过dataprovider的集中管理让插件开发者对每一次查询上心，这是最伟大的副产品，比之drupal和joomla把数据库服务器当本机缓存这种不负责任的做派，好得多。
至于语法，基本上，都相当简洁：