DBISAM与BDE的不同之处.docVIP

DBISAM与BDE的不同之处 与BDE的不同点之处： 　　应该被指出，BDE和DBISAM有几个非常关键的差异，特别是当你要把已经使用BDE的应用程序转换为DBISAM时。请注意，这里所有的对比都是假定仅仅在BDE可用的Paradox和dBase/FoxPro本地数据库基础上，因为很多原因在比较时没有包括Access。 　　BLOB： 　　BDE(在Paradox数据库中)允许存储部分BLOB数据到一个给定的在实际数据记录中存储的BLOB字段，除非你存储BLOB到一个独立的BLOB文件。DBISAM不支持这么操作，而是更像dBase那样把所有BLOB数据单独存储在一个独立的BLOB文件中。DBISAM总是在记录被增加或编辑时缓存BLOB在内存中，相比起来，BDE一般在BLOB数据超过内存消耗可接受限度时，把它们保存在磁盘上的临时文件里（可接受限度由BDE 决定）。 　　数据备份： 　　DBISAM目前没有batch move组件，但是通过SQL INSERT和UPDATE语句提供大量的插入和更新，同样能达到目的。 　　高速缓存更新： 　　DBISAM也不支持高速缓存更新。同样，你也可以通过内存表和事务轻松达到同样的功能。 　　并行操作（多用户）： 　　一般说来，BDE很难适当设置为多用户使用，尤其是Paradox。这需要处理.NET文件、.LCK文件和设置本地共享，如果设置不恰当就会导致数据刷新困难，严重时导致数据毁坏和数据丢失。使用DBISAM，所有的锁定均由操作系统完成，而不需要涉及任何外部配置文件。你绝对不需要为单用户和多用户做任何额外的工作，所有难做的工作都已经替你做好了，你惟一要做的就是把表复制到网络服务器上。 　　如果手工刷新没有执行，BDE一般不会提供本地缓存里的最新数据，所以不同的客户可能会看到不同的数据。DBISAM允许你通过 TDBISAMSession组件的StrictChangeDetection属性选择怎样提供数据流。使用严格的改变检测 (StrictChangeDetection=True)可以确保DBISAM总是返回最新数据。使用延时的改变检测 (StrictChangeDetection=False)会导致DBISAM不一定返回最新数据，这和BDE的默认特性一样，但是性能却大大提高！延时的改变检测是TDBISAMSession组件的默认属性，然而，BDE和DBISAM（使用延时的改变检测）都会确保使用最新的数据更新数据库。 DBISAM的改变检测选项也能由同一个应用程序中的多个TDBISAMSession组件混合决定。 　　分发： 　　DBISAM可以完全编译到你的应用程序中而不需要任何其他DLL或附加控件，运行期包也为Delphi3分发DBXXXXXR.DPL，为 Delphi4/5分发DBXXXXXR.BPL并为C++Builder 3/4/5提供支持（这里的XXXXX前三位由DBISAM的3位版本号替换，比如200就是2.00版，再用一个D表示Delphi或一个C表示 C++Builder，最后一位表示一个版本号，比如3表示Delphi3）。 　　加密和用户安全： 　　BDE通过把Paradox用户口令加密而包含用户安全支持。DBISAM也支持用口令对一个表进行加密，但是目前不支持基于用户的加密机制。每当你尝试对一个加密的DBISAM表进行任何操作时，你就会被提示需要口令。你必须特别注意这个功能，因为你可能会因为忘掉口令而不能打开一个加密表。 　　过滤： 　　BDE和DBISAM都提供条件过滤和基于OnFilterRecord事件描述的过滤机制，因此你可以过滤任意类型的数据。无论是BDE还是 DBISAM，条件过滤都是由数据库引擎进行最优化。这就是说，一个部分或全部符合过滤条件的可用索引（不管主从）总是找到合适的记录，而不是从上到下对实际数据记录进行扫描。不管是BDE还是DBISAM都要记住：FilterOptions属性设置的ixCaseInsensitive影响着哪一个索引对这个最优化过程有效（大小写敏感和大小写不敏感），但是这仅仅针对String字段来说。如果对一个非字符串（如整型）字段设置过滤，ixCaseInsensitive设置就和最优化过程无关。如果你想弄清楚一个特定的过滤是否可优化，只要检查TDBISAMTable组件的 FilterOptimizeLevel属性就行。DBISAM用bitmaps和索引执行过滤优化使用了Rushmore技术，这一点与FoxPro和 dBase使用的技术差不多。符合过滤条件的记录次序和BDE的记录计数完全一样。 　　空闲空间管理： 　　BDE在Paradox中实行剩余空间循环利用，在FoxPro和dBase中却不能循环利用，这些数据库表经过