无处不在的抽象惩罚

[莫华枫]

抽象惩罚不光语言里有，在业务开发的时候也有。
我以前做过一个面向对象的数据库中间层，把数据库的数据包装成对象，并且在对象上建立关联。差不多是这样：
班级信息里包括班主任、学生列表、班长等等属性，可以直接取出所需的对象，或者对象集合。这种抽象最好，业务层的开发不必跟数据库死缠烂打。
但是如果我要打印一个年级的所有班级的学生清单，那么必须遍历这个班级集合，然后挨个取出班级上的学生，再取出学生的信息，组织成打印数据，执行打印。这样在逻辑上很干净，但是性能则不尽如人意。每当取出一个班级，就必须以该班级为索引，查询数据库，获得学生清单。造成频繁的数据库操作和网络访问。性能很差。反而使用传统的sql，可以直接通过join，一次性获得所有的结果，在客户机上处理。
这就是业务开发中的抽象惩罚。所以，现在多数的业务开发都无法采用很好的抽象，同样也只能将数据结果集强类型化，基本上还是直接操作数据库。
解决的办法是有的，就是让sql也面向对象。但是，这不是一般的企业能够搞得，而数据库生产商也没有做oodb的动力。开发工具是进步了，但我们的底层构架还没有跟上。

--
反者道之动，弱者道之用
m...@seaskysh.com
longsh...@gmail.com
http://blog.csdn.net/longshanks/

[Fisher]

你指O/R Mapping?

[red...@gmail.com]

我不认为底层用 oodb 是好事情.

对于企业来说, 基础数据是宝贵的, 有价值的, 应该用可靠, 可以用多种语言, 多
种编程范式访问的方式保存.

具体业务逻辑是可变的, 不持久的. 将数据的存储和这些东西混杂在一起并无好
处, 会损害数据的可用性, 甚至破坏数据的长久价值.

对编程者, OO 封装用来防御变化, 但是对于企业, 数据的长久价值, 数据的深入
挖掘, 都是建立在一个相对稳定的数据模型上的, 偏向编程者的方式不能给企业带
来更好的利益.

我认为在高层用更好的手段来适应业务代码更喜欢的 OO 模型和底层的 RDBMS 模
型才是好的处理方法, 目前的 ORM 是单纯地让 RDBMS 模型去适应 OO 模型, 未必
是合适的.

并且, 高层的 OO 设计, 未必是先设计好个体对象, 然后再考虑个体之间的关系才
是正招.

对应某些应用, 先考虑好这些关系, 给这些关系设计好抽象的访问模型, 然后再设
计个体, 可能能同时兼顾内存访问性能和数据库访问性能.

莫华枫 写道:
> 抽象惩罚不光语言里有，在业务开发的时候也有。
> 我以前做过一个面向对象的数据库中间层，把数据库的数据包装成对象，并且在

[pongba]

On Dec 11, 2007 5:32 PM, <red...@gmail.com> wrote:

我不认为底层用 oodb 是好事情.

对于企业来说, 基础数据是宝贵的, 有价值的, 应该用可靠, 可以用多种语言, 多
种编程范式访问的方式保存.

具体业务逻辑是可变的, 不持久的. 将数据的存储和这些东西混杂在一起并无好
处, 会损害数据的可用性, 甚至破坏数据的长久价值.

对编程者, OO 封装用来防御变化, 但是对于企业, 数据的长久价值, 数据的深入
挖掘, 都是建立在一个相对稳定的数据模型上的, 偏向编程者的方式不能给企业带
来更好的利益.

我认为在高层用更好的手段来适应业务代码更喜欢的 OO 模型和底层的 RDBMS 模
型才是好的处理方法, 目前的 ORM 是单纯地让 RDBMS 模型去适应 OO 模型, 未必
是合适的.

并且, 高层的 OO 设计, 未必是先设计好个体对象, 然后再考虑个体之间的关系才
是正招.

对应某些应用, 先考虑好这些关系, 给这些关系设计好抽象的访问模型, 然后再设
计个体, 可能能同时兼顾内存访问性能和数据库访问性能.

精辟啊！赞！

--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

[莫华枫]

啊，这个问题么，这么说吧。
对于实际应用db是oo还是er不是核心问题。不管是什么db，持续化都是基础，数据安全都是可以保证的。关键是对业务数据和数据关系的表达。从数据处理角度来看，er更加方便和直接；而从业务模型的角度来看，oo则更符合人的思维。
oodb的oo实际上并不适合。严格地讲，oodb的oo和oop的oo还不一样。oodb更侧重于adt。
比如我们经常为了性能，把一个表拆成若干个表（有一个抽象惩罚），比如帐务系统按月存放凭证单据，并且存放每个月的期初和期末数，便于快速地获得某些统计数据。但是，从业务角度来讲，只关心这些统计数据，至于如何来的，则无需费心。在传统的ui-erdb两层模型中，这种底层实现对于业务实现都是可见的，必须处理这些workaround。而adt在这里则起到屏蔽层的作用。业务模型无需关心底层的实现，不管业务数据存放在几个表里，上层的业务流程代码都是一样的。这就方便了软件的改进和调校。
adt同时还提供了非原子类型的导出，将数据对象之间的关联以成员的形式表示，通过类上的成员获取关联的数据对象。
现在很多三层以上的软件模型，基本上都存在这么一个er到oo的映射层，通常都是手工打造的。我过去做的那个东西，就是这个映射层的自动化，打算构成一个通用平台，服务多种软件。但是由于技术和条件，以及我的能力限制，没有达到令人满意的效果。但是从使用上来看，的确方便了某些方面的操作（非查询性的数据访问）。
纯oodb的问题在于，按oo存储对象没有问题，但如何才能将这些对象组织起来，提供高效方便的数据查询，是个棘手的问题。似乎至今也没有哪家厂商处理好这个问题。
oql和sql3实际上都是er数据库的oo化。前者侧重于oo，而后者侧重于er。但是无论如何，对象化的sql，在实际使用中都是必不可少的。

回到主题说两句：实际上，即便是er，也存在很多抽象惩罚。比如我们就很少使用第3以上的范式，主要都是为了性能考虑。

On Dec 11, 2007 5:32 PM, < red...@gmail.com> wrote:

longsh...@gmail.com
http://blog.csdn.net/longshanks/

[red...@gmail.com]

做一个好的映射层是困难的.

我曾经偷懒用过另外的方法, 当时的应用不需要 runtime 生成不同的映射. 所以
我用 powerdesigner 将库结构 dump 出来(这样, 对不同的数据库, 有一个通用的
格式), 然后用 python 分析这些 sql, 根据给明的一些指示信息, 让 python 直
接生成一堆的访问代码, 进行一些 OR map, 同时兼顾单个的访问和带关系的数据
fetch.

这样比写一个通用的 or mapping 层简单很多.
> 现在很多三层以上的软件模型，基本上都存在这么一个er到oo的映射层，通常都
> 是手工打造的。我过去做的那个东西，就是这个映射层的自动化，打算构成一个
> 通用平台，服务多种软件。但是由于技术和条件，以及我的能力限制，没有达到
> 令人满意的效果。但是从使用上来看，的确方便了某些方面的操作（非查询性的

[莫华枫]

的确如此。
通用的东西通常都是很麻烦的。

longsh...@gmail.com
http://blog.csdn.net/longshanks/

[徐梓鼎]

为啥不使用表分区？在应用层上解决底层应该解决的问题，不嫌麻烦？难道统计的
SQL都要写两套吗？

在2007-12-12来自"莫华枫" <longsh...@gmail.com>的邮件[[TopLanguage]
Re: 无处不在的抽象惩罚]中写到：

> 比如我们经常为了性能，把一个表拆成若干个表（有一个抽象惩罚），比如帐务
> 系统按月存放凭证单据，并且存放每个月的期初和期末数，便于快速地获得某些
> 统计数据。

--
DEBUG是件快乐的事情 <xuzi...@gmail.com>

[莫华枫]

表分区？不太明白。

--
DEBUG是件快乐的事情 <xuzi...@gmail.com>



longsh...@gmail.com
http://blog.csdn.net/longshanks/

[徐梓鼎]

嗯，对呀，比如某个表 有一个月份字段，当前这个月的是要被非常频繁的访问的
，而其他的则是历史数据，那么就可以按照这个月份字段将表分区，只要你的条件
里面有这个月份，就可以做到和单独建表差不多的效率，大型数据库上都应该有才
对。下面内容来自google
Oracle：
表分区技术是在超大型数据库(VLDB)中将大表及其索引通过分区（patition）的
形式分割为若干较小、可管理的小块，并且每一分区可进一步划分为更小的子分区
（sub partition）。而这种分区对于应用来说是透明的。通过对表进行分区，可
以获得以下的好处：

　　1）减少数据损坏的可能性。

　　2）各分区可以独立备份和恢复，增强了数据库的可管理性。

　　3）可以控制分区在硬盘上的分布，以均衡IO，改善了数据库的性能。
DB2：
表分区特性提供以下收益：
表数据可轻易实现转入和转出
对大型表的管理更加轻松
灵活的索引放置
更高的业务智能样式查询的性能

在2007-12-12来自"莫华枫" <longsh...@gmail.com>的邮件[[TopLanguage]
Re: 无处不在的抽象惩罚]中写到：

> 表分区？不太明白。

--
DEBUG是件快乐的事情 <xuzi...@gmail.com>

[莫华枫]

这个效率依赖于月份上的索引，效率的确比单独表相差不大。但是如果牵涉到其他字段的混合查询，性能还是差很多的。而且也替代不了阶段性的汇总值带来的性能提升。
在数据方面的更多的性能提升依赖于先期的数据汇总处理，典型的就是olap

[徐梓鼎]

在2007-12-13来自"莫华枫" <longsh...@gmail.com>的邮件[[TopLanguage]
Re: 无处不在的抽象惩罚]中写到：

> 这个效率依赖于月份上的索引，效率的确比单独表相差不大。但是如果牵涉到其他字段的混合查询， 性能还是差很多的。
表分区和不是索引，即便是牵涉到其他字段的查询，只要你的查询条件里面有月份
，那么数据库首先找到这个月份的分区，然后再根据索引去查询，相当于限制了要
扫描的数据量，和你人肉分表效果几乎一致。你可以测试一下。

> 而且也替代不了阶段性的汇总值带来的性能提升。在数据方面的更多的性能提升依赖于先期的数据汇总处理，典型的就是olap

当然这个是无法替代阶段性的汇总值带来的性能提升，但是可以让业务处理一致起
来，不至于一个业务要对于两个不同的表，写两套不同的SQL。
对于阶段性的汇总，为什么不在业务上进行分离，单独建表来提升性能，为何一定
要分表？

--
DEBUG是件快乐的事情 <xuzi...@gmail.com>

[莫华枫]

因为业务上是同一个东西，结构相同，逻辑上分表和实现上分表操作上一回事，但在业务实现上增加复杂性。业务上不分，可以在维持业务实现不变的情况下，针对不同的应用对象，采用不同的底层实现，提高灵活性。这也是多层模型的精髓所在。

[Eli]

LZ的问题完全是自己的心理障碍再做怪.

首先要说明的是, 非常赞同redsea的意见. 其次要说明的是, 数据结构本身就是抽象, 只是和建模的角度不同.

最后你这个问题, 是因为切入的角度错误, 班级可以是一个类, 但班级无论在现实生活中还是在任何概念中, 仅仅是用来分类的对象. 比如如果上升到
区教育局的系统, 你这个设计还是按班处理? 还是变成把班级的概念换成学校了事? 具体怎么设计, 个人有个人的做法, 但是错的设计一下自己就能看
出来的, 错的设计不能认为是规则的惩罚, 而是对错误的惩罚.

另外补充一点是, 当涉及到数据传输的时候, 比如数据库到业务服务器, 业务服务器到客户端, 如何打包是必要研究的. 我个人的思路是, 必须按过
程打包, 即该过程需要什么数据应该一次传输. 对于在业务逻辑或者客户显示逻辑而言, 用不着的数据, 在这一刻, 应该和不存在等价. 说实话,
我个人在别处参与的大多数这种讨论, 甚至包括Fowler的言论, 都有一个重大缺陷, 就是忽略对过程所需的数据及对象的集合的预测和计算.
CPU还有个分支预测呢不是. 领域建模的核心就是, 开机后所有对象都是被假设存在的, 而这在物理上又不可能, 于是出来的种种框架和OODB这类
东西来追求对数据操作的透明化, 这是一个错误的方向.

面向对象不代表就要忽视过程本身和物理限制所产生的特征, 面向对象是手段, 不是目的, 也不是结果.

P.S. 不打算讨论这个问题太多, 天天在Java/C#社区争吵这个, 没想到这里也看见了 -___-

> longshank...@gmail.comhttp://blog.csdn.net/longshanks/

[Eli]

>对于在业务逻辑或者客户显示逻辑而言, 用不着的数据, 在这一刻, 应该和不存在等价.

也就是说, 用到的数据, 应该是就绪状态的. 至于如何就绪, 为什么你在就绪上遇到麻烦, 都是因为不是按过程处理, 而迁就最初被错误设计的模型
所代来的惩罚.

[Eli]

最后要说明的是, 多层模型的精髓所在, 还有很多很热的东西的精髓所在, 根本不是我们业务的精髓所在.

就我对C#/Java社区的观察, 大家关注于各种解决方案和所谓"企业应用架构模式"过多, 以至于反而忽略了真正带来复杂性的那些东西: 我们的系
统是干嘛的, 如何更好的达到这一目标. 不是产生需求, 再选择实现, 而是先产生概念和选择框架, 然后反过来限制了从需求到实现的手段.

而在围绕需求做设计的时候, 又忽略一个隐含的需求, 即我们是要让计算机更好的工作, 而不是为了把自己脑子里的各种概念, 强加到计算机身上. 被
忽略的隐性需求经常有: "只能使用关系数据库"这一事实, 比如, "需要传输数据对象"这一事实, 比如, "一个界面或一个逻辑, 需要且仅需要
某一组数据"这个事实(于是如何将对象恢复到内存中居然也会遇到种种不爽), 而是先来个什么什么框架, 再来一个多么符合面向对象的建模(其实往往
只是自己脑子里觉得这样设计合适), 接着其它问题接踵而至, 最后要么忍受, 要么搞个workaround.

这样可不是会得到一个结论, 即关系模型和面向对象是冲突的, LZ说的这种情况, C#/Java社区见得太多了... 这种讨论和每个人对事物认知
的方式所相关, 且这认知事物的方式方法是本质复杂性, 不可能顿悟. 也许是你有问题, 也许是我有问题, 最后肯定会变成谁也说不服谁的无结果讨
论. 这在C#/Java社区, 每次都是这个样子.

唉, 又忍不住瞎说了. 如果LZ不认同, 只当胡说八道吧, 千万别让我再参与这种讨论了. 我也不是Fowler, 没兴趣宣传某些理念, 只当是
道不同, 不相为谋好了.

[Eli]

"错的设计不能认为是规则的惩罚, 而是对错误的惩罚"

这句话错了, 是"往往大多数不爽, 不能认为是规则的惩罚, 而是对错误设计的惩罚".

[Anson]

呵呵， 借用一句老话， 如果锤子砸了脚， 我们不应该去怪锤子吧。

[莫华枫]

这不是心理障碍。对于我们这些成天跟语言几角旮旯打交道的人而言，直接的er数据处理更加舒服自然。但是对于业务专家而言，oo的形式更易于接受。程序员毕竟是分不同层次的。我遇到过很多程序员，他们跟客户混久了，对于业务甚至比客户本身还熟，但编程，特别是复杂数据处理，实在是...
所以，抽象化的数据表达并非为了所有的开发人员，是为了那些没有能力，或者没有心思处理数据的人设立的。数据对象化之后，对于同那些软件开发的行外人交互，也更加容易。通常，他们给出的需求，都更容易用oo或ob进行表达。

[Eli]

你说的有道理, 咱们是不是太小看客户了?

你看, 客户玩关系型数据, 可是有几百年历史了.., 现在的居委会大妈还在玩..

> longshank...@gmail.comhttp://blog.csdn.net/longshanks/

[Eli]

另外我也不是说, "直接的er数据处理", 而是说建模时的看过去的角度, 往往决定了最后对对象的使用是否是别扭的..

On Dec 14, 7:44 pm, "莫华枫" <longshank...@gmail.com> wrote:

> longshank...@gmail.comhttp://blog.csdn.net/longshanks/

[莫华枫]

你说的对。
我现在很少直接做业务了，有时候在设计上掺和一下，往往想着想着，就变成数据库设计了。在我们看来很自然的数据表达，很难向用户描述。而用户角度描述的数据对象和结构，通常在数据处理方面并非很合理。这大概也算是对矛盾吧。

longsh...@gmail.com
http://blog.csdn.net/longshanks/

[buhongbo]

>> 面向对象不代表就要忽视过程本身和物理限制所产生的特征, 面向对象是手段, 不是目的, 也不是结果.

>> 错的设计不能认为是规则的惩罚, 而是对错误的惩罚

 

完全赞同！！

 

---

buhongbo

2007-12-17

---

发件人： Eli

发送时间： 2007-12-14 18:00:48

收件人： TopLanguage

抄送：

主题： [TopLanguage] Re: 无处不在的抽象惩罚

[red...@gmail.com]

莫华枫 写道:

啊，这个问题么，这么说吧。
对于实际应用db是oo还是er不是核心问题。不管是什么db，持续化都是基础，数据安全都是可以保证的。关键是对业务数据和数据关系的表达。从数据处理 角度来看，er更加方便和直接；而从业务模型的角度来看，oo则更符合人的思维。
oodb的oo实际上并不适合。严格地讲，oodb的oo和oop的oo还不一样。oodb更侧重于adt。
比如我们经常为了性能，把一个表拆成若干个表（有一个抽象惩罚），比如帐务系统按月存放凭证单据，并且存放每个月的期初和期末数，便于快速地获得某些统计 数据。但是，从业务角度来讲，只关心这些统计数据，至于如何来的，则无需费心。在传统的ui-erdb两层模型中，这种底层实现对于业务实现都是可见的， 必须处理这些workaround。而adt在这里则起到屏蔽层的作用。业务模型无需关心底层的实现，不管业务数据存放在几个表里，上层的业务流程代码都 是一样的。这就方便了软件的改进和调校。

  这里我之前的做法, 是抛弃数据库系统的可移植性, 让数据库系统来应付性能需求.
  例如按月存放这种, 真的需要分表, 那么我会使用表分区这种很多数据库都支持, 但是互不兼容的技术来做, 高层不去理解这些差别.
  其实, 现在的数据库, 如果只是应付查询的话, 几亿条记录的查询速度并不慢; 当然, 如果一个大表要同时应付大量的查询以及更新, 就会慢了. 这种情况, 之前我用过的方法是, 本日插入的数据(这里有插入, 加锁, 更新, 提交之类东西), 是单独放到一个大逻辑表中的一个分区表里面的, 当日做日结的时候(日结完毕就基本只做查询了, 哈哈, 除了红字冲销之类的), 将它挪到大分区表中去.

adt同时还提供了非原子类型的导出，将数据对象之间的关联以成员的形式表示，通过类上的成员获取关联的数据对象。
现在很多三层以上的软件模型，基本上都存在这么一个er到oo的映射层，通常都是手工打造的。我过去做的那个东西，就是这个映射层的自动化，打算构成一个 通用平台，服务多种软件。但是由于技术和条件，以及我的能力限制，没有达到令人满意的效果。但是从使用上来看，的确方便了某些方面的操作（非查询性的数据 访问）。

纯oodb的问题在于，按oo存储对象没有问题，但如何才能将这些对象组织起来，提供高效方便的数据查询，是个棘手的问题。似乎至今也没有哪家厂商处理好 这个问题。
oql和sql3实际上都是er数据库的oo化。前者侧重于oo，而后者侧重于er。但是无论如何，对象化的sql，在实际使用中都是必不可少的。

回到主题说两句：实际上，即便是er，也存在很多抽象惩罚。比如我们就很少使用第3以上的范式，主要都是为了性能考虑。

  所谓的设计工作, 就是综合考虑 业务, 技术平台, 技术人员能力和人力, 时间和成本, 最后做出来的折衷啊.

  要说抽象惩罚, 很多时候还不止是性能惩罚, 例如可能是目标拟合不准确, 而造成后续更多任务过来的时候, 很难表达.

  需要用到抽象, 就是说你没有办法用完全契合的方法来描述对象, 只能用简化对象特性, 甚至做模型映射的方法来描述对象, 肯定无法做到完全符合, 肯定是要碰到 "惩罚"的.

  就拿地图来说, 你将地球仪球表面剥开, 还摊不平在桌子上呢, 地球的球表面需要用几种映射方法之一换算到平面, 这一步就已经失真了, 无论当初两地距离量得多么准确, 上下两端都满是皱褶无法紧贴(抽象漏洞 ? 所以小时候一直觉得南极洲很大的.) 这种地图, 平时我们大家用, 当然没有问题, 但如果我们要跑到南极冒险, 还拿这个地图, 就险上加险了 (问题的覆盖广泛度和深度不同, 同一个抽象的适应程度不同).

  rdbms 和 oo 是两个不同的模型, 面向两个不同的问题域(两个问题域都很有价值), 他们之间要结合, 理论上是没有完全自动化, 没有任何惩罚或者泄露的方法的, 因为他们根本就不是同一套方法, 就像球表面法 vs 平面法一样,  就象我们在三维空面无法准确重现四维的东西一样 ---- 如果非要希望完美结合, 除非我们跳到一个更高的层面上, 这个层面中, 这两个模型只是大模型在两种情况下的特化, 但即使有这个大模型, 这个大模型也会太过复杂了, 不符合成本原则, 从而不能用于我们的 "设计".

 

[莫华枫]

是啊，的确是这样。
所以我现在在公司里主张设法淡化不同形式的数据表达同应用程序业务层的接驳差异。首先建立一种能够表达任何一种数据结构的接口，不管是erdb返回的结果集，还是oodb（或orm）返回的对象集合。然后，使得ui上可以方便快速地绑定到这些接口上。最后，逐步开发不同结果集的适配模块。这样，我们便可以针对不同的应用，使用合适的数据访问操作，甚至可以在同一应用程序里交叉使用。比如，对于数据录入、设置、构建，oo形式方便，而对于数据查询，则er的sql更加灵活强大。

[up duan]

我觉得主要原因是：我们程序员总是试图以自己所写的应用逻辑为主要立足点来观察整个世界。但实际上，大多数商业系统，其核心是数据，更具体的说就是数据库。所以，我们应该以它们为基础看问题。

数据库给我们提供了相当丰富的抽象手段和机制。Table是基础。View给我们不同的视角看待数据。Trigger给我们事件以及处理的绑定。……，其实，数据库系统给我们多少抽象惩罚呢？我觉得大多数情况下，它给我们的比我们设想的还好，我不认为一个人针对一个具体的业务模型【更具体的说是数据模型】抽象出来的框架比数据库的关系型框架能好多少，而且一般情况下是更差。