Pro*C还是OCI？

做C/C++做ORACLE开发，是PRO*C好还是OCI好？

PRO*C和OCI各有特色吧！

PRO*C的好处就是学习难度低，开发效率高，对于数组类型的宿主变量绑定也很方便，如果都使用批量执行的话，性能也是很高的。PRO*C在C/C++代 码中嵌入SQL，然后proc预编译器将pc文件翻译成c或cpp文件，再由GCC编译成目标文件。微软近几年推出了LINQ，相比ORACLE多年前推 出的PRO*C，这又是照虎画猫的伎俩。本质上来说，proc预编译器只是一个代码生成工具，RPO*C中对数据库的操作最终还是转换成了对OCI的调 用。

PRO*C不好的地方在于其语法和原生的C/C++语法有冲突，如果不熟悉，常常就会发生使用proc无法编译通过的现象。而且很多特殊的场合，需要很多 技巧来绕过proc编译器，在GCC编译器的层面又要绕一次。对于高级开发方面，PRO*C就完全无能为力了，毕竟PRO*C提供的语法有限，功能有限。

OCI应该说是ORACLE最基本最底层的调用接口，相信其他的所有ORACLE客户端工具都是调用OCI的API来实现的（比如sqlplus, sql*loader, pl/sql developer, Pro*C, ADO.NET for Oracle等）。OCI使用C风格的函数提供接口，洋洋洒洒的成百上千个函数中覆盖了ORACLE数据库操作的方方面面。

OCI的学习难度高，开发效率也不高，执行效率方面，由于没有任何的封装，理论上来说是最高的，但是执行效率和使用者的水平有很大关系，使用不当，很容易 开发出糟糕的ORACLE应用。高级开发方面，最吸引我的莫过于批量执行和直接路径加载，其他的高级功能也都包含在OCI库中。

然而，OCI的开发难度可以通过封装来降低。封装一个好用的OCI库非常有意义：封装采用的是原生的C/C++语法，不是PRO*C这样的怪异语法，相比 之下编译期遇到的问题容易解决，并且在配合template等高级技巧方面也容易得多。（PRO*C在开发的时候都小心翼翼的，唯恐加多了代码编译不过 去）

甚至，可以自己开发一个代码生成工具，通过映射数据库的Schema来自动生成对表的CRUD代码，这样的话，OCI的开发效率就可以与PRO*C媲美了。

对于批量执行，直接路径加载等功能也进行封装的话，使用这些高级功能更能大大提高执行效率，这点是PRO*C望尘莫及的。

总结一下，个人认为：对于小的、要求快速开发完成的、软件生命周期短，且不需要什么高级功能的ORACLE应用，PRO*C还是相当不错的，学习难度低，开发效率高。

对于高性能、高稳定性、对结构要求清晰，且时间执行的服务器软件等，用OCI更好（当然是封装后的OCI，不封装简直等于自找苦吃）。代码的清晰性，高级功能等方面，OCI更加灵活和方便。


·Pro*C和Pro*C++是不同的，主要在预编译器proc的命令行参数上体现区别；
    个人的感觉是Pro*C的检查语法要严格一些，比如变量一定要写在DECLARE SECTION里面，否则就编译不过，而PRO*C++只需要把需要绑定的变量写在DECLARE SECTION里面就行了。
    在绑定宿主变量方面，PRO*C要比PRO*C++好些，用了PRO*C++后，特别是绑定结构体的时候，结构体识别不了。
·Pro*C对PL/SQL语法的支持是有限的，典型的就是不支持INNER JOIN, LEFT OUTER JOIN等语法，还有不支持WITH等语法。因此对于一些新奇的语法，最好先写个小例子程序来试试能不能编译过，不然，编译不过的时候等着哭吧…………