二进制数据文件中的碎片(50分)

Z

zfh

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2002-02-03

• #21

//每次保存时都要遍历文件中闲置空间并向其中插入新数据的算法?
我想你的理解有误。
数据库的逻辑存储与物理存储是两回事，比如说你的逻辑第二条记录不一定在物理存储上紧跟在第一条之后。你根本无法
定位你的物理闲置空间。也就是说，这个问题的发生与操作系统的磁盘存储管理相关。这与磁盘的碎片表现不同，但实质是一样的。

 

Z

zfh

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2002-02-03

• #22

一列队伍中，只能容纳一个瘦人的空间要硬塞进一名胖子，那么后面的人势必都要调整位置，
如果你一定要这么做，意味着每一次操作都进行一次重整，这个代价太昂贵了，以至于没有一种
数据库会这么做，只能定期重整。
如果你所说的是”小峰电子书库“的话，它的源代码可以从其网站得到（www.mycnknow.com），如果
无法下载，给作者写信索取。
TinyDB其实就是用于作类似于”电子书库“这样的东东用的微型数据库，不过可以像真正的数据库一样
维护罢了。其内置了三种强度极高的加密算法。 2.6版有中文帮助，下一个版本也会有。

 

P

Pipi.

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2002-02-03

• #23

info长度变化很大的话，那么最好把它解脱出来放在另外一个文件，基本文件上保存它在另外的
文件的offset和长度。基本文件仍然保留固定长度纪录比较简单

 

M

Maxying

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2002-02-05

• #24

To:zfh
非常感谢你的帮助，我看了小峰的源代码，因为我是用C++ Builder开发的，所以他的Delphi
代码只能看懂一部分了，也许是没看得很细的原因，它用的是TMemoryStream而我用的是TFileStream
虽然这两个实现上基本没区别，但我好像没看到他保存文件时对存储结构的处理。
也许想你所说的我的想法有问题，但我觉得像我上面所说的问题确实存在，尽管我不管第二段文字
是否物理上与第一段文字相连，我当然不会每次存盘时都进行文件中的碎片整理（当然不是操作系统的碎片整理），
而是提供相应的程序在用户需要时整理，但碎片问题你是一定要处理的，因为你打开文件后
每读取一段文字都要根据偏移量和长度，而如果读入后发现这篇文章没结束，还应该找到这篇文章后半部分
的偏移量继续读取，你觉得呢？

 

Z

zfh

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2002-02-05

• #25

我明白了，没有现成的“数据驱动”的情况下，文件碎片问题的确要自己解决，我把前提条件忽略了。
只在有驱动（或者叫引擎）的条件下，数据文件才可以认为是没有逻辑碎片的。

 

M

Maxying

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2002-02-06

• #26

那像“小峰书库”那样左边有树状视图，右边是具体文章，它是否将索引单独保存呢？我看
他的源代码好像是直接将TreeView->SaveToStream();根本没管节点与数据的关系

 

M

Maxying

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2002-02-07

• #27

呜呜~~~ 又没人理我了！~~~