类型保护API

如何消除数据库损坏

SmartEDB 原生 API 是类型保护的：数据类型错误在编译时就会被捕捉到，从而消除数据库损坏。
嵌入式数据库函数库具有便利性、可移植性和生产率等优点，但其构建和使用方式会导致错误。这些应用程序编程接口（API）几乎总是对数据结构一无所知——它们在处理数据时并不知道其类型。这极大地限制了编译器和运行时执行任何验证的能力，大大增加了编程错误在质量保证中被遗漏的可能性。

麦克·对象公司的 SmartEDB 数据库系统通过引入类型安全的 API 而向前迈出了巨大的一步。在其原生 API 中，SmartEDB 为诸如打开和关闭数据库等基本任务提供了一组有限的静态函数。然而，大多数用于与给定数据库设计进行交互的函数是在使用 SmartEDB 的 mcocomp 数据库定义语言（DDL）编译实用程序编译模式时生成的。

由于这些函数“知晓”它们预期要处理的数据类型，所以在应用程序编译时就能捕获赋值错误，而不是在发布之后，此时解决问题通常要昂贵得多。这种办法还具有额外的好处，即能创建出更直观、更易于学习的编程接口。由 SmartEDB 生成的接口比为与无穷多种数据库设计配合使用而设计的静态接口中的函数更具可读性和自文档性。开发人员确切地知道正在执行何种操作以及操作的是何种数据，而且项目引入破坏性错误的风险也大大降低。

调试运行时

SmartEDB 的另一道防止数据库损坏的防线是其调试库集。在源代码中，SmartEDB 开发人员已嵌入了不同级别的健全性检查，以帮助应用程序开发人员查找并消除在使用 SmartEDB API 时出现的错误。SmartEDB 随附两组库：1）完全优化版，禁用了健全性检查；2）完整调试版，启用了所有健全性检查。当然，健全性检查需要额外的代码大小和执行时钟周期。源代码授权用户可以构建具有不同调试级别的其他库集。健全性检查确保开发人员以预期的方式使用 SmartEDB API。例如，它会优雅地捕获在事务已关闭（已提交或已中止）后尝试使用事务句柄的情况。而优化运行时则会直接发出致命错误。当团队成功编译了系统，并且所有质量保证测试在调试库中都已通过，就可以将系统重新链接到优化的运行时环境中，以最小化代码大小并恢复宝贵的时钟周期，同时可以高度确信所有与数据库相关的应用程序缺陷都已发现并修复。

循环冗余校验（CRC）校验

除了通过使用类型安全的 API 和调试库主动防止数据库损坏之外，SmartEDB 运行时还可以配置为计算页面级的 CRC 校验和，并在每次获取页面时验证校验和。这可用于检测对数据库内容的未经授权的篡改，例如试图绕过数字版权管理或其他数据库访问安全措施。