衔接层属性可上可下, 针对项目可应该对方案进行对比, 应该在最适合逻辑的KISS上进行方案的选择, 如有成功的case, 应该最大参考, 这和产品是不一样的.
我个人倒是认为没有绝对的方案只有适合方案.如果楼主开发的应用不关注或者不够关注信息的类型,属性全用string事倍功半的话,也没必要非抱着传统的关点不放.
我是希望程序开发能够简化的,只是对忽略属性数据类型有几点理不通:
1.业务数值运算。
大凡商业应用都与数值紧密相联,毕竟商业最关注就是钱,钱可只能是数值,这也决定不少的业务操作都进行数值计算.如果属性全采用string,这些数值计算在什么地方进行,将数据加载到业务层,进行转型计算不太可能,现在的硬件无法承受这种运算方式;推至数据库来进行转型、计算，好象也不太妥，即牺牲了性能，也增加了复杂性。
2.安全性
忽略属性数据类型后，必然要引入类型校验，毕竟，虽然存储上忽略了数据类型，但是，很多数据，你是有数据类型预期.但是利用代码来进行数据类型检查无疑增加了程序出错的可能性。
顺便提一下，我个人比较推崇客户端脚本和业务类双校验数据，业务类的操作可能存在多个操作入口，未必只是给一个web操作使用(例如用户update业务接口可能会给create,modify及其它操作也会用到),甚至可能c/s也会使用这个业务类(例如，招商银行既有b/s网上银行，也有c/s的网上银行)，所以严谨些的商业应用，业务层的数据校验应该是完整的。客户端的校验主要为了降低用户输入正确数据的成本。至于web层的数据校验，在有明确的业务层的框架里倒是可有可无。
3.程序可读性
一个人写程序还好，协同开发的话，所有方法的api注释恐怕都得注明数据类型。国内的程序开发本来就缺乏严谨性，做为设计人员怎么敢做这样的设计，这样会给使用接口的程序员带来麻烦，万一接口的开发人员在方法内部没做较好的数据校验，这种错误很有可能会在第三个程序员的程序才报错。
4.设计的合理性
我们是根据信息的现实模型来限定信息的数据类型，它之所以为这种类型，极有可能会有后续的类型操作。暂时忽略类型，也许带来了一时的简化，但是更大的可能是带来了将来的开发量，未必得偿所失。
综而言之，忽略数据类型的设计需多多考虑，别图了一些的方便，引来更大的麻烦。
不太明白是什么意思楼主提到的动态表是什么意思？是否应用需要能创建表，并维护表数据。如果是这样的话，hibernate和ofbiz都提供了很好的模型供参考,比较关键的是创建表的同时，需要顺便生成一份对应文件，便于将来获取数据。这种框架一般都要具有较强通用性，如果忽略了数据类型，远而言之，不是好事。
刚才拜读板桥兄的<<数据库时代已经过去>>，吓了偶一跳。
我不是钻板桥的牛角尖。前几天看国美的单日销售额破2000万，估计单笔交易额也就1000左右，一个订单按1k存储，一天一个店就是20M,国美按10个店算，一天就是200M，一年是360*200M,再打个折，算40G.这是主营业务的数据一项，实际上相关的支援数据（采购，仓管，物流）再低也在10倍以上。那一年国美得花掉400G的内存，如果再加上办公之类的，国美轻轻松松可以破个1000G。7x24小时的软硬件向来都不便宜，国美就算有点银子，也应该花不起这个钱。电信，移动，银行可就更惨了。据我所知，有的公司一天的硬盘数据备份就得花200G，而且只是备份差异，不是备份完整，并且备份只不过确保两周内的数据可恢复。N怀疑板桥兄现在是不是被内存商收买了.
第三程序也没法应用，除非根据内存里的数据开发接口。
呵呵，偶还是安安心心等好用的面向对象数据库。
skyleaf24想法有个小问题：缓存不是数据库的替代，数据库里的数据不能全部都拿到缓存里，缓存是数据动态运算的暂存地，这和CPU的缓存都是同一个道理，为什么同一级别的CPU，多些缓存性能会提高很多。
本帖不是讨论缓存，但是看到很多人对缓存和数据库对立，特地补充一下。
对于skyleaf24担心的设计问题，因为我们坚持解耦 灵活是最大的设计目标，统一成String与这一设计目标不矛盾，而且简化易读，唯一的考虑是性能：但是如果我们通过缓存降低数据库的访问频率，注意不是替代数据库访问，数据库端的性能损耗是忽略不计算的。
有人说并发量很大时，恐怕这点性能损耗不能忽略，关键是：并发量大时，经过中间服务器的缓存+无态Service对象池对付拦截，已经完成处理，不必再访问数据库，只有一部分访问量会加到数据库上。
另外中间服务器可以通过多台服务器集群，增大缓存，拦截处理完成到大部分请求。这是一个可伸缩的解决方案。
非常感谢大家发表了这么多意见。得出一个结论，模型架构没有万能的，关键看适合应用在哪里。banq兄提的方式对于很多基于表，业务运算较少的应用中，会体现出很大的简易优势。对于复杂应用，继续采用准确类型的方式，大家也没什么异议。
>不太明白是什么意思楼主提到的动态表是什么意思？是否应用需要能创建表，并维护表数据。如果是这样的话，hibernate和ofbiz都提供了很好的模型供参考,比较关键的是创建表的同时，需要顺便生成一份对应文件，便于将来获取数据。这种框架一般都要具有较强通用性，如果忽略了数据类型，远而言之，不是好事。
感谢skyleaf24清晰的剖析。我想实现的动态表就是，让产品发布后，实施人员可以根据客户的具体需要，定制一些数据栏位，或增加一些业务表。对于动态加入的字段可以体现在原有的开发界面上，并进行简单的数据显示和保存。而完全新增的表可以对其进行基本的增删改。由于我的系统中有公式解析器，因此这些新增的字段可以参与到公式中，从而实现一定的算法、查询过滤条件、报表等。由于要采用OO的设计，又要将动态机制（从业务角度是非OO的，基于表的方式）引入进来，很多模型和细节要考虑。关于引入动态体系，我会在思想较为成熟时，另行开贴。至于sky兄所讲hibernate里有相应的模型，我不太明白。
呵呵，我对很多性能方面的问题研究的不是很多，只是认为这跟现实中的情况有些类似。
讨论这样的问题好比是在讨论有钱好，还是有生活必须品好。有了钱（对应用String表示所有类型），可以买到任何商品，不过你得跑去买，方便与否关键在于买的时候坐什么交通工具。如果是有东西（自立更生），虽然生活不愁也方便，但是与别人交换东西又不方便，这里又体现了货币的价值。
理想的社会也就是共产主义社会（最体现优越性的，虽然未实现），只要大家都付出劳动（底层识别），不需要交换东西，不需要货币，需要什么就给什么，是不是最佳实现呢，计算机的世界没有人性的自私，这种共产主义社会是可能实现的----动态语言：）
恩～～，我也觉得应该具体问题具体分析，如果系统逻辑计算不是很多，可以同String提高开发速度，反之最好还是不要这样，尤其是一些float，double类型，对以后系统的维护和扩展非常不利
个人认为.其实改成string有个很大的好处.可以很简单的处理null.
毕竟string可以很简单的处理null.但是int,datetime不能.
请问如果用String代替date类型的话，如何实现查询表时的排序(即按时间顺序)，因为字符串的排序和date很不一样。还有就是比如我要查询时间段，又如何实现？请大家帮忙解答一下
>用String代替date类型的话，如何实现查询表时的排序
这个可以参考JiveJdon3源码，在JiveJdon3中，时间都是以字符串保存，字符串也是按大小排的啊。