看了几天 ZODB 的东西，自己的一点看法

作者："Can Xue" 发表时间：Wed, May 23 2007 4:00 am

由于这是我初次接触对象数据库，对其它的对象数据库完全无知，对 OQL 也没有任何的了解，写的东西难免幼稚，欢迎大家拍砖。

与关系数据库将数据拆分为记录的各个字段保存到表中不同，在面向对象的数
据库中，程序员可以用任何方式组织保存在数据库中的对象。在这个方面，目
前还没有通用的标准。因此，需要有一个有效的手段来规范我们如何组织这些
对象。

在关系数据库领域，当程序从数据库中获取一条记录的时候，获取的是这条记
录的一个副本。应用程序在此基础上修改这条记录，对数据库中的信息没有任
何影响，直到应用程序明确的通过专门的查询语句更新这条记录，告诉数据库
需要被更新的信息和条件，对数据的修改才完成。因此，关系数据库在这个时
刻有机会触发相应的机制进行诸如建立或调整索引这样的操作。记录本身不需
要也不太可能知道它被保存在何处，也不知道有哪些附加在操作如索引作用于
这条记录。获取、更改和删除记录的操作是通过凌驾于记录之上的存储结构，
通常是表来完成的。

在类似 ZODB 这样的持久化存储系统中，一切都不一样了。应用程序从 ZODB
中获得一个对象，概念上是获得了这个对象的实例而不是副本，对这个实例进
行修改，这样的修改至少理论上应该立刻体现在永久性的存储设备中。开发人
员可以自己决定这个对象保存在数据库中的哪个位置，这里没有表的概念，持
久化存储系统可以看成是开发人员内存的扩展，加上能持久保存数据的能力。
因此，如果需要引入类似交叉索引以提升查询对象的效率，程序员需要使用完
全不同于关系数据库的方法来处理。

开发人员可能需要建立自己的索引机制，这样的机制也应该表现为一个可以持
久化保存的对象。而正常的对象需要知道有那些索引机制对它发生作用，在处
理对象属性的修改时，对象需要明确告知相应的索引机制自己的属性已经改变，
让这些索引机制决定是否需要对其中的索引数据进行调整，或者告知相应的对
象这种属性的改变是否违背了程序员事先约定的规则。

上面的解决方案是建立在应用程序从持久化存储设备获取对象实例的基础上。
可以获取实例本身而不是副本是持久化存储的一个特性。当然开发人员也可以
建立这样的机制，让应用程序获得的是一个对象的副本，然后通过明确的保存、
修改或者删除的声明来和存储层打交道。一个可能的极端就是，在持久性存储
系统的基础上，实现一套关系数据库的功能。不过，既然市场上已经有了那么
多出色的关系数据库产品，我不认为有这么做的必要。

ZODB 的持久化存储的一个特点是以对象的可到达性来作为持久化的基础。在
ZODB 中，存在一个体现为映射结构的根节点。所有保存在 ZODB 中的对象都能
从这个根节点通过某种或者简单或者复杂的路径被访问到。对象可以直接作为
根节点的一个条目被加入。根节点的某个条目可以是另外一个映射对象或者序
列对象，对象可能被加入这样的映射或者序列中。对象还可以作为某个已经可
以被访问到的对象的属性被加入到持久化系统中。从概念上说，在对象数据库
中组织对象的结构，可以是队列、树、树林、图或者是任意的程序员决定采用
的数据结构。

在 ZODB 邮件列表上经常看到的一句话是：使用关系数据库，查询语言是 SQL、
使用 ZODB，查询语言是 Python。这句话需要被深刻的理解。使用程序设计语
言本身查询数据意味着更强大的功能，比如使用复杂的正则表达式或者通过某
个符合特殊需求的函数进行查询更加容易；也意味着查询的过程可能更加复杂，
除非程序员为规范常用的查询行为建立相应的模型，否则查询的操作可以相当
的随意。同时，如果开发人员组织数据的结构不够理想，事实上也经常如此，
那么查询的效率将完全得不到保证。

选择类似 ZODB 这样的持久化存储系统，摆在开发人员面前的第一个问题，也
可能是永恒的问题是，如何在规范存储和操作行为上和保留直接存取对象的方
便性之间，谋求一种可以被接受的平衡。

--
薛粲

有耕耘方能有收获，愿能与您顺心携手共成长。

作者：bluesea 发表时间：Wed, May 23 2007 9:24 pm
使用关系数据库，查询语言是 SQL、
使用 ZODB，查询语言是 Python

呵呵，也有同感，急需一个标准！

感觉即使为了一个简单的查询等等操作，都很"麻烦"

On 5月23日, 下午4时00分, "Can Xue" <xue...@gmail.com> wrote:

- Hide quoted text -
- Show quoted text -
> 由于这是我初次接触对象数据库，对其它的对象数据库完全无知，对 OQL 也没有任何的了解，写的东西难免幼稚，欢迎大家拍砖。

> 与关系数据库将数据拆分为记录的各个字段保存到表中不同，在面向对象的数
> 据库中，程序员可以用任何方式组织保存在数据库中的对象。在这个方面，目
> 前还没有通用的标准。因此，需要有一个有效的手段来规范我们如何组织这些
> 对象。

> 在关系数据库领域，当程序从数据库中获取一条记录的时候，获取的是这条记
> 录的一个副本。应用程序在此基础上修改这条记录，对数据库中的信息没有任
> 何影响，直到应用程序明确的通过专门的查询语句更新这条记录，告诉数据库
> 需要被更新的信息和条件，对数据的修改才完成。因此，关系数据库在这个时
> 刻有机会触发相应的机制进行诸如建立或调整索引这样的操作。记录本身不需
> 要也不太可能知道它被保存在何处，也不知道有哪些附加在操作如索引作用于
> 这条记录。获取、更改和删除记录的操作是通过凌驾于记录之上的存储结构，
> 通常是表来完成的。

> 在类似 ZODB 这样的持久化存储系统中，一切都不一样了。应用程序从 ZODB
> 中获得一个对象，概念上是获得了这个对象的实例而不是副本，对这个实例进
> 行修改，这样的修改至少理论上应该立刻体现在永久性的存储设备中。开发人
> 员可以自己决定这个对象保存在数据库中的哪个位置，这里没有表的概念，持
> 久化存储系统可以看成是开发人员内存的扩展，加上能持久保存数据的能力。
> 因此，如果需要引入类似交叉索引以提升查询对象的效率，程序员需要使用完
> 全不同于关系数据库的方法来处理。

> 开发人员可能需要建立自己的索引机制，这样的机制也应该表现为一个可以持
> 久化保存的对象。而正常的对象需要知道有那些索引机制对它发生作用，在处
> 理对象属性的修改时，对象需要明确告知相应的索引机制自己的属性已经改变，
> 让这些索引机制决定是否需要对其中的索引数据进行调整，或者告知相应的对
> 象这种属性的改变是否违背了程序员事先约定的规则。

> 上面的解决方案是建立在应用程序从持久化存储设备获取对象实例的基础上。
> 可以获取实例本身而不是副本是持久化存储的一个特性。当然开发人员也可以
> 建立这样的机制，让应用程序获得的是一个对象的副本，然后通过明确的保存、
> 修改或者删除的声明来和存储层打交道。一个可能的极端就是，在持久性存储
> 系统的基础上，实现一套关系数据库的功能。不过，既然市场上已经有了那么
> 多出色的关系数据库产品，我不认为有这么做的必要。

> ZODB 的持久化存储的一个特点是以对象的可到达性来作为持久化的基础。在
> ZODB 中，存在一个体现为映射结构的根节点。所有保存在 ZODB 中的对象都能
> 从这个根节点通过某种或者简单或者复杂的路径被访问到。对象可以直接作为
> 根节点的一个条目被加入。根节点的某个条目可以是另外一个映射对象或者序
> 列对象，对象可能被加入这样的映射或者序列中。对象还可以作为某个已经可
> 以被访问到的对象的属性被加入到持久化系统中。从概念上说，在对象数据库
> 中组织对象的结构，可以是队列、树、树林、图或者是任意的程序员决定采用
> 的数据结构。

> 在 ZODB 邮件列表上经常看到的一句话是：使用关系数据库，查询语言是 SQL、
> 使用 ZODB，查询语言是 Python。这句话需要被深刻的理解。使用程序设计语
> 言本身查询数据意味着更强大的功能，比如使用复杂的正则表达式或者通过某
> 个符合特殊需求的函数进行查询更加容易；也意味着查询的过程可能更加复杂，
> 除非程序员为规范常用的查询行为建立相应的模型，否则查询的操作可以相当
> 的随意。同时，如果开发人员组织数据的结构不够理想，事实上也经常如此，
> 那么查询的效率将完全得不到保证。

> 选择类似 ZODB 这样的持久化存储系统，摆在开发人员面前的第一个问题，也
> 可能是永恒的问题是，如何在规范存储和操作行为上和保留直接存取对象的方
> 便性之间，谋求一种可以被接受的平衡。

> --
> 薛粲

> 有耕耘方能有收获，愿能与您顺心携手共成长。

作者："Keins Ruite" 发表时间：Wed, May 23 2007 10:22 pm
对象数据库的普及将是数据库程序开发的一个转折点啊~

不知道对象数据库在性能和安全，稳定性上现在如何，能否替代和满足或者现有的关系数据库的全部应用

Regards,
Keins Ruite . aBBISh

- Hide quoted text -
- Show quoted text -
-----Original Message-----
From: python-cn@googlegroups.com [mailto:python-cn@googlegroups.com] On Behalf Of bluesea
Sent: Thursday, May 24, 2007 9:24 AM
To: python.cn
Subject: [CPyUG:26908] Re: 看了几天 ZODB 的东西，自己的一点看法

使用关系数据库，查询语言是 SQL、
使用 ZODB，查询语言是 Python

呵呵，也有同感，急需一个标准！

感觉即使为了一个简单的查询等等操作，都很"麻烦"

On 5月23日, 下午4时00分, "Can Xue" <xue...@gmail.com> wrote:
> 由于这是我初次接触对象数据库，对其它的对象数据库完全无知，对 OQL 也没有任何的了解，写的东西难免幼稚，欢迎大家拍砖。

> 与关系数据库将数据拆分为记录的各个字段保存到表中不同，在面向对象的数
> 据库中，程序员可以用任何方式组织保存在数据库中的对象。在这个方面，目
> 前还没有通用的标准。因此，需要有一个有效的手段来规范我们如何组织这些
> 对象。

> 在关系数据库领域，当程序从数据库中获取一条记录的时候，获取的是这条记
> 录的一个副本。应用程序在此基础上修改这条记录，对数据库中的信息没有任
> 何影响，直到应用程序明确的通过专门的查询语句更新这条记录，告诉数据库
> 需要被更新的信息和条件，对数据的修改才完成。因此，关系数据库在这个时
> 刻有机会触发相应的机制进行诸如建立或调整索引这样的操作。记录本身不需
> 要也不太可能知道它被保存在何处，也不知道有哪些附加在操作如索引作用于
> 这条记录。获取、更改和删除记录的操作是通过凌驾于记录之上的存储结构，
> 通常是表来完成的。

> 在类似 ZODB 这样的持久化存储系统中，一切都不一样了。应用程序从 ZODB
> 中获得一个对象，概念上是获得了这个对象的实例而不是副本，对这个实例进
> 行修改，这样的修改至少理论上应该立刻体现在永久性的存储设备中。开发人
> 员可以自己决定这个对象保存在数据库中的哪个位置，这里没有表的概念，持
> 久化存储系统可以看成是开发人员内存的扩展，加上能持久保存数据的能力。
> 因此，如果需要引入类似交叉索引以提升查询对象的效率，程序员需要使用完
> 全不同于关系数据库的方法来处理。

> 开发人员可能需要建立自己的索引机制，这样的机制也应该表现为一个可以持
> 久化保存的对象。而正常的对象需要知道有那些索引机制对它发生作用，在处
> 理对象属性的修改时，对象需要明确告知相应的索引机制自己的属性已经改变，
> 让这些索引机制决定是否需要对其中的索引数据进行调整，或者告知相应的对
> 象这种属性的改变是否违背了程序员事先约定的规则。

> 上面的解决方案是建立在应用程序从持久化存储设备获取对象实例的基础上。
> 可以获取实例本身而不是副本是持久化存储的一个特性。当然开发人员也可以
> 建立这样的机制，让应用程序获得的是一个对象的副本，然后通过明确的保存、
> 修改或者删除的声明来和存储层打交道。一个可能的极端就是，在持久性存储
> 系统的基础上，实现一套关系数据库的功能。不过，既然市场上已经有了那么
> 多出色的关系数据库产品，我不认为有这么做的必要。

> ZODB 的持久化存储的一个特点是以对象的可到达性来作为持久化的基础。在
> ZODB 中，存在一个体现为映射结构的根节点。所有保存在 ZODB 中的对象都能
> 从这个根节点通过某种或者简单或者复杂的路径被访问到。对象可以直接作为
> 根节点的一个条目被加入。根节点的某个条目可以是另外一个映射对象或者序
> 列对象，对象可能被加入这样的映射或者序列中。对象还可以作为某个已经可
> 以被访问到的对象的属性被加入到持久化系统中。从概念上说，在对象数据库
> 中组织对象的结构，可以是队列、树、树林、图或者是任意的程序员决定采用
> 的数据结构。

> 在 ZODB 邮件列表上经常看到的一句话是：使用关系数据库，查询语言是 SQL、
> 使用 ZODB，查询语言是 Python。这句话需要被深刻的理解。使用程序设计语
> 言本身查询数据意味着更强大的功能，比如使用复杂的正则表达式或者通过某
> 个符合特殊需求的函数进行查询更加容易；也意味着查询的过程可能更加复杂，
> 除非程序员为规范常用的查询行为建立相应的模型，否则查询的操作可以相当
> 的随意。同时，如果开发人员组织数据的结构不够理想，事实上也经常如此，
> 那么查询的效率将完全得不到保证。

> 选择类似 ZODB 这样的持久化存储系统，摆在开发人员面前的第一个问题，也
> 可能是永恒的问题是，如何在规范存储和操作行为上和保留直接存取对象的方
> 便性之间，谋求一种可以被接受的平衡。

> --
> 薛粲

> 有耕耘方能有收获，愿能与您顺心携手共成长。

作者："Can Xue" 发表时间：Thurs, May 24 2007 8:03 am

我的理解是，不管对象数据库还是关系数据库，最终都是将数据持久化的存储在某个存储设备上。因此，性能是由底层的存储引擎决定的，如 MySQL 的
MyISAM 性能就优于 InnoDB，但是 InnDB
则具有更全面的功能。这是典型的由使用目的不同决定了数据结构不同造成的相应算法在时间复杂度上的差异。所以，性能一定要结合使用方法来考察。

讨论对象数据库的文章经常的引用一段话是："
利用表格存储对象，就象是将汽车开回家，然后拆成零碎件放进车库里，早晨可以再把汽车装配起来。但是人们不禁要问：这是不是泊车的最有效的方法呢"。如果我们的­需求是我现在要车牌号为
苏A-12345 的车，那么对象数据库性能肯定更优越，如果我们的需求是请找出停车场里所有装有 JBL
环绕立体声音响的车，目前看来应该是关系数据库性能更优越，如果泊车的时候把每辆车的配置都登记并索引了的话。

安全性的问题简单说就是在存储在磁盘中的文件和用户或者程序之间增加一道安全门。理论上说，只要攻击者能够直接访问存储设备，所有的安全性都将很脆弱，不过事实­上由于要分析这样"赤裸"的文件需要相应的技巧或者库，因此相对来说还是安全的。通过网络的访问，安全性则取决于网络通讯服务模块。理论上讲不管什么系统，这上­面的安全性都是一样脆弱(或者采用某种同样性质同样强度的加密措施后是一样安全)的，问题在于这部分代码是否经受了时间的考验，代码本身是否有什么后门可以被攻­击者利用。

稳定性的东西需要时间考验，所以目前应该是那些经受了时间考验的流行的关系数据库系统胜出。

人们在已经有了许多优秀的关系数据库的时候，会把对象数据库的概念抛出来，多多少少是由于某些情形下使用关系数据库让开发人员感觉到某种痛苦。而对象数据库可以­很好的解决这些痛苦。问题是，至少目前，对象数据库在解决了某些痛苦的时候，原来在关系数据库领域非常方便根本不是问题的问题却出现了。我认为对象数据库需要内­置提供更强大的检索机制，只有开发人员用起来感觉"爽"，它才能真正成为主流产品，否则，只能是学者在实验室把玩的模型，并且小范围的应用在一些非常不适合使用­关系数据库的领域(今天，各种关系映射模型日渐成熟，数据量小的时候还可以考虑类似
XML 这样的存储和交换数据的解决方案，因此非常适合对象数据库非其不能以胜任的领域还确实不多)。

在07-5-24，Keins Ruite <ops.t...@gmail.com> 写道：

- Hide quoted text -
- Show quoted text -

> 对象数据库的普及将是数据库程序开发的一个转折点啊~

> 不知道对象数据库在性能和安全，稳定性上现在如何，能否替代和满足或者现有的关系数据库的全部应用

> Regards,
> Keins Ruite . aBBISh

> -----Original Message-----
> From: python-cn@googlegroups.com [mailto:python-cn@googlegroups.com] On
> Behalf Of bluesea
> Sent: Thursday, May 24, 2007 9:24 AM
> To: python.cn
> Subject: [CPyUG:26908] Re: 看了几天 ZODB 的东西，自己的一点看法

> 使用关系数据库，查询语言是 SQL、
> 使用 ZODB，查询语言是 Python

> 呵呵，也有同感，急需一个标准！

> 感觉即使为了一个简单的查询等等操作，都很"麻烦"

> On 5月23日, 下午4时00分, "Can Xue" <xue...@gmail.com> wrote:
> > 由于这是我初次接触对象数据库，对其它的对象数据库完全无知，对 OQL 也没有任何的了解，写的东西难免幼稚，欢迎大家拍砖。

> > 与关系数据库将数据拆分为记录的各个字段保存到表中不同，在面向对象的数
> > 据库中，程序员可以用任何方式组织保存在数据库中的对象。在这个方面，目
> > 前还没有通用的标准。因此，需要有一个有效的手段来规范我们如何组织这些
> > 对象。

> > 在关系数据库领域，当程序从数据库中获取一条记录的时候，获取的是这条记
> > 录的一个副本。应用程序在此基础上修改这条记录，对数据库中的信息没有任
> > 何影响，直到应用程序明确的通过专门的查询语句更新这条记录，告诉数据库
> > 需要被更新的信息和条件，对数据的修改才完成。因此，关系数据库在这个时
> > 刻有机会触发相应的机制进行诸如建立或调整索引这样的操作。记录本身不需
> > 要也不太可能知道它被保存在何处，也不知道有哪些附加在操作如索引作用于
> > 这条记录。获取、更改和删除记录的操作是通过凌驾于记录之上的存储结构，
> > 通常是表来完成的。

> > 在类似 ZODB 这样的持久化存储系统中，一切都不一样了。应用程序从 ZODB
> > 中获得一个对象，概念上是获得了这个对象的实例而不是副本，对这个实例进
> > 行修改，这样的修改至少理论上应该立刻体现在永久性的存储设备中。开发人
> > 员可以自己决定这个对象保存在数据库中的哪个位置，这里没有表的概念，持
> > 久化存储系统可以看成是开发人员内存的扩展，加上能持久保存数据的能力。
> > 因此，如果需要引入类似交叉索引以提升查询对象的效率，程序员需要使用完
> > 全不同于关系数据库的方法来处理。

> > 开发人员可能需要建立自己的索引机制，这样的机制也应该表现为一个可以持
> > 久化保存的对象。而正常的对象需要知道有那些索引机制对它发生作用，在处
> > 理对象属性的修改时，对象需要明确告知相应的索引机制自己的属性已经改变，
> > 让这些索引机制决定是否需要对其中的索引数据进行调整，或者告知相应的对
> > 象这种属性的改变是否违背了程序员事先约定的规则。

> > 上面的解决方案是建立在应用程序从持久化存储设备获取对象实例的基础上。
> > 可以获取实例本身而不是副本是持久化存储的一个特性。当然开发人员也可以
> > 建立这样的机制，让应用程序获得的是一个对象的副本，然后通过明确的保存、
> > 修改或者删除的声明来和存储层打交道。一个可能的极端就是，在持久性存储
> > 系统的基础上，实现一套关系数据库的功能。不过，既然市场上已经有了那么
> > 多出色的关系数据库产品，我不认为有这么做的必要。

> > ZODB 的持久化存储的一个特点是以对象的可到达性来作为持久化的基础。在
> > ZODB 中，存在一个体现为映射结构的根节点。所有保存在 ZODB 中的对象都能
> > 从这个根节点通过某种或者简单或者复杂的路径被访问到。对象可以直接作为
> > 根节点的一个条目被加入。根节点的某个条目可以是另外一个映射对象或者序
> > 列对象，对象可能被加入这样的映射或者序列中。对象还可以作为某个已经可
> > 以被访问到的对象的属性被加入到持久化系统中。从概念上说，在对象数据库
> > 中组织对象的结构，可以是队列、树、树林、图或者是任意的程序员决定采用
> > 的数据结构。

> > 在 ZODB 邮件列表上经常看到的一句话是：使用关系数据库，查询语言是 SQL、
> > 使用 ZODB，查询语言是 Python。这句话需要被深刻的理解。使用程序设计语
> > 言本身查询数据意味着更强大的功能，比如使用复杂的正则表达式或者通过某
> > 个符合特殊需求的函数进行查询更加容易；也意味着查询的过程可能更加复杂，
> > 除非程序员为规范常用的查询行为建立相应的模型，否则查询的操作可以相当
> > 的随意。同时，如果开发人员组织数据的结构不够理想，事实上也经常如此，
> > 那么查询的效率将完全得不到保证。

> > 选择类似 ZODB 这样的持久化存储系统，摆在开发人员面前的第一个问题，也
> > 可能是永恒的问题是，如何在规范存储和操作行为上和保留直接存取对象的方
> > 便性之间，谋求一种可以被接受的平衡。

> > --
> > 薛粲

> > 有耕耘方能有收获，愿能与您顺心携手共成长。

--
薛粲

有耕耘方能有收获，愿能与您顺心携手共成长。

作者：bluesea 发表时间：Sun, May 27 2007 9:22 pm
我觉得的确什么样数据库的使用都应该是根据某一定时间内的某些需求所决定的，对象数据库有对象数据库的优势，关系数据库有关系数据库的优势，只是在当下
人们用了关系数据库有 N 年了，已经很了解很熟悉了，不过我还是相信对象数据库会"好"起来的，只是时间问题，因为当人们对"对象"这个概念逐渐熟悉
的时候，也会慢慢的接纳对象数据库的吧，现在还基本停留在"表格"上:)