冰云同志的一些似是而非的想法

冰云同志已经好久没写blog了，以至于我已经遗忘了他的blog的存在，今天查subversion的配置，从BJUG的主页连过去看看，竟然意外的发现他又写了几篇...粗看一遍，汗啊...

http://blog.nona.name/archives/167.html

这篇叫强类型的烦恼...哎，里面的观点很古怪。
第一个，弱类型数据库，这简直就是胡说八道！momo同学...你该跟我去听听体系结构了。
String作为一种类型，其实并不适宜计算机处理，一个简单的例子100，用二进制就是01，定长也不过16-32位，"100"呢？这是一个复杂类型，要记录长度3，还有每一位的数据。至少需要4个8位整，如果转成unicode，就更无法想象了。如果说数据量大还是小问题，计算问题就更大了。一个整数加法，基本上就是一个计算周期，而使用字符串呢？按位加，还得记录进位。如果大家写过高精度加法算法就知道了，不太复杂，但是很慢，于是数据库的内置计算字段就废掉了。比较可能还要复杂一些，而且字符串比较没有缺省语义，还得算。所以从目前的计算机体系结构角度考虑，直接的字符存储是没有好处的。
第二个，你的假设的出发点，是一类CMS系统，CMS并不以计算为主的。
基于web的应用开发（主要指利用web作为ui的系统，而基于web server使用http remoting的东西不算），本质上也就是一种序列化, 将业务对象以某种文本格式序列化出来，如果这个业务对象本身承载了很少的计算语义，比如comment, article, product description 那么使用数据库，不过是从一种持久形式转化为另一种持久形式。那么为什么还要使用数据库呢？为什么不直接使用XML + XSLT或者就是静态HTML来处理呢？
第三点，至于Domain修改。
用一个架构常识性观点来考虑这个问题，直接在ui里使用domain的结构是这样的

 UI html  --〉 Action          HBM<---DB Scheam
       \                |                  |
        D o m a i n         M o d e l
一种典型的扁平结构(当然物理结构扁平是一种有效的架构系统的手法),你算一下domian model依赖权重，或者直接用眼睛观察一下，是不是所有东西都依赖于Domain？那么Domain改了，系统如何能不修改？因此不是强类型的问题，而是系统结构的问题。而且这个矛盾使用一般结构很难解决...所以要减少domain变化，这也是一个常识。所以你每次都跟我说,domain有这样，这样以及这样等等 你对于domain的不确定性才是domain变化的原因，而不是技术因素。