分子结构式的表达和存储
化学分子结构式的表达方法有很多。最基本的方法当然就是图片文件，图片文件的确仅适用于展示，不适用于分析和检索。常见的以文本形式存储的化学结构包括InChI，SMILES，Molfiles，CML等。对于这些格式，在inchi.info网站上有一个不错的比较。原文还带有一些注释。
| InChI | InChIKey | SMILES | Molfile | CML | |
| 线性（不用换行） | Yes | Yes | Yes | No | No |
| 唯一性 | Yes | No | Possibly | No | No |
| 可读性 | Hardly | Impossible | Easily | Hardly | Hardly |
| 定义原子几何位置 | No | No | No | Yes | Yes |
| 长度（每原子字符数） | ~2 | ~1 | 1-2 | ~50 | ~50 |
| 软件支持 (0-1) | 0.3 | 0.1 | 0.2 | 1 | 0.5 |
在数据库中作为结构式信息进行存储，比较重要的考虑因素就是唯一性、存储空间。所以使用InChI, SMILES作为结构式的描述信息都可行。
这个表里需要注意的是，InChIKey与Molfile/CML在唯一性上都是No，但有很大不同。不同的分子结构有可能用同一个InChIKey表达；同一个分子式，可以表示成不同的Molfile/CML。这都对数据库中的 一项重要工作，检索带来大麻烦。
找到合适的分子结构式表达方式，用文本的方式存储起来，并不复杂。执行一些简单的操作，比如通过分子结构（精确）查找分子，也和普通的数据库操作没什么两样。
但是要通过结构式信息进行分子参数计算、子结构检索、描述符（fingerprint）生成及索引、分子相似性计算等工作时，往往需要在关系数据库上增加插件来实现。
关系数据库插件 (cartridge)
下面的插件，没有一个是应用于MS SQL Server的。SQL Server也提供了扩展存储过程(SQL Server 2000)及CLR(SQL Server 2005)等插件接口，是能够实现相同的功能的。这也正是我现在正在进行的工作。
pgchem::tigress
开源。用在PostgreSQL上。在checkmol/matchmol 和OpenBabel的基础上开发的。文档很nice，但是似乎很久没有更新了。典型的案例是http://www.chemcollect.de/
mychem
开源。用在MySQL上，UDF形式的插件。基于OpenBabel。SVN代码更新比较勤。
OrChem
This project aims at creating an open source chemistry plugin / cartridge for the relational database system Oracle.
其他商业插件
- CambridgeSoft Oracle Cartridge
- Symyx Direct, Cartridge for Oracle
- CHORD, a commercial chemical cartridge for PostgreSQL, is sold by gNova. 基于OEChem。OEChem也不是免费的。
- JChem Cartridge, adds chemical intelligence to the Oracle platform.
一本新书
Design and Use of Relational Database in Chemistry，《在化学领域设计和使用关系数据库》。作者是gNova公司的TJ O’Donnell, Ph. D.，那这本书里用到的方法，也自然是这个公司的CHORD插件了。不过这本书对关系数据库中，化学信息的应用，写得比较全面和系统了（从目录上看）。就是有点灌水，连关系数据理论都要占一章。写一本书，讲解理论的同时推销自己的产品，还能挣稿费，这绝对是个好办法。Amazon上的定价是$93.56。
不需要插件的解决方案
Chemical Substructure Search in SQL
Adel Golovin and Kim Henrick,
EMBL-EBI Hinston Hall Genome Campus, Cambridge, U.K.
J. Chem. Inf. Model., Article ASAP
DOI: 10.1021/ci8003013
这是一篇发表不久的文章。我很感叹之前为什么没有过这么直接的思路。分子结构用SMILES表达的原理中，实际上就已经将分子结构抽象为原子(Atom)和键(Bond)之间的组合，并且用生成树(spanning tree)构造成字串。
分子、原子、键、分子结构(spanning tree)，都可以，而且很适合在关系数据库中表达出来。子结构检索等功能操作，也可以用基本的SQL来实现。
相对于用插件的方案，优势在于
- 不限制于数据库平台。
- 更稳定。插件的质量高低，运行于何种进程空间，是否会出现异常，都将直接影响服务器。在重要的运营服务器上，更是隐患。
- 性能(performance)更优。对原子和键的查询都可直接利用数据库服务器的索引。
- 存储空间上（可能）有改善。当设计得当时，原子、键建立字典表，事实表就都是数字组成的关联表。在基于插件的系统中，以子结构检索为例，为了尽量减少性能消耗最大的插件函数计算，往往会生成碎片(fingerprint)索引，所使用的存储空间，加上SMILES的字符串存储空间，会高于这个方案中的存储空间。尤其是在小分子数据库中。
其他参考资料
Fast Substructure Search series, by Rich Apodaca
How to create a web-based molecular structure database with free software[PDF], by Norbert Haider (Checkmol/matchmol)