 [原创]Firebird数据库值得信赖吗？为什么我要在开发中选择它？ |
1、Firebird是一个真正的关系数据库，支持存储过程、视图、触发器、事务等大型关系数据库的所有特性；
2、Firebird支持SQL92的绝大部分命令，并且支持大部分SQL99命令，新版Firebird 2.0对SQL99的支持更完整；
3、Firebird源码基于成熟的商业数据库Interbase，有良好的稳定性，与Interbase有良好的兼容性；
4、不用考虑授权费用（免费），不用当心将来有一天你或你的客户因为使用盗版而被数据库开发商告上法庭；
5、发布简易，安装文件只有几M，且高度可定制，客户端的分发也很简单，只需一个DLL文件；
6、Firebird的一嵌入式服务器版本，不用安装，直接运行，基于单机开发首选；
7、Firebird的运行效率非常高；
8、具备高度可移植性，可在Linux,Unix,MacOS,Windows,Solaris系统下运行，而且数据库格式完全一样，不用修改；
9、开发环境支持良好，Delphi,C++Builder不用通过ODBC连接，直接用原生开发接口开发基于Firebird的程序。
|
|
|
还有其他特性：
1．支持事件，这个特性很好，很多商业数据库都没有，如sql server,DB2都没有.
2. 支持数组字段，这个sql server还不支持．
3 支持计算字段，这个sql server还不支持．不过作用不是很大．
4 触发器功能比很多商业数据库都强大
好处讲了，我现在讲企业级应用还缺少的地方(^..^大家不要对我扔香蕉呀）：
1. 不支持分布式服务， 如在触发器中或存储过程中也访问其他的FB数据库现在没有解决方法．只能通过前台程序进行解决．
2 Supserver模式不的线程不支持多处理器．这个可能要等到FB3.0才能解决．
3 不支持数据分发与订阅，现在ＭＩS系统一般都要求数据即集中又独立，这个就要数据的分发与订阅服务．当然即使支持服务，写这样的管理系统时数据库设计要需要很多的技巧的．不过通过第三方工具可以支持．见网站：www.meta.com.au 有一个FBReplicator工具
4 不支持全文检索，不过可以通过第三方工具支持,见以下网站： http://www./cs/database/FulltextFirebird.asp
现讲些鸡毛算皮的
1 不支增量备份，只有完全部分．对于特大的数据库时，完全备分就会有些不便了．
2 没有事务日誌(因是ＭＧＡ），也就是不存在日誌备份，不过这个有不有作用不是很大．
3 基本的内置函数缺少．写存储过程与触发器时得找些第三方函数库，或自己写自定义函数，这个即有坏处也有好处，坏处是影响了开发效率，好处是程序员可以写出功能强大的适合本系统的函数．相当于sql server的自定义存储过程．
4 安全性不好，破解FB的数据库密码相当容易，只要把原生secury.fdb数据库覆盖你服务器同名的数据库，sysdba管理员的密码就恢复到masterkey ，这个只能怪开源太透明什么都告诉你，假设你知sql server 安全数据资料存放在什么地方，我相信每个人破解sa 密码也是很容易的．
5 过程与触发器代码不能加密码，这样自己系统的业务逻辑很容易被泄露．像sql server可以加蜜，不过其加密是假，在网上随便下个工具就可以破解，不过sql server可以写成dll形式的外部存储过程（哈哈，就是fb的自定义函数）
6 数据精度不可，不过对一般的中小型应用来说是够了．
7 不支持临时表，这个比sql server退步点，不过他有外部文件表，哈哈比sql server有进步．
|
| |
7 不支持临时表，这个比sql server退步点，不过他有外部文件表，哈哈比sql server有进步
什么是外部文件表? |
| |
这个指的是在firebird中数据库的表,他的表数据是以文件形式存在磁的,例如:
CREATE TABLE HELL
EXTERNAL FILE ‘extal.fs‘ (
ADDREE CHAR(10) NOT NULL,
NAME CHAR(10))
以上将建一个extal.fs的文件来保存表HELL的数据,extal.fs文件的路径由FB的配置文件中的ExternalFileAccess选项决定,如ExternalFileAccess=c:\windows 那么extal.fs的全路径是:
c:\windows\extal.fs
这种表用来与其他的数据源交源数据是相当方便的. |
| 回复：[原创]Firebird数据库值得信赖吗？为什么我要在开发中选择它？ |
[QUOTE][b]以下是引用haha168在2005-8-24 22:47:40的发言：
过程与触发器代码不能加密码，这样自己系统的业务逻辑很容易被泄露．像sql server可以加蜜，不过其加密是假，在网上随便下个工具就可以破解，不过sql server可以写成dll形式的外部存储过程（哈哈，就是fb的自定义函数）
[/QUOTE]
这一条有异议，好象可以在编译之后把存储过程的文本删掉，没的试过，有兴趣的可以试试（注意先做好备份）
FB怎么对存贮过程进行加密
用firebird开发的系统,发布后,用户可以打开数据库并看到存储过程源码,如何加密存储过程不让用户查看.
很简单, 修改系统表 RDB$PROCEDURES 的字段 RDB$PROCEDURE_SOURCE
的内容即可, 我是这样的:
UPDATE RDB$PROCEDURES
SET RDB$PROCEDURE_SOURCE = NULL
(RDB$PROCEDURE_BLR 是编译后的二进制代码, 删除源代码不影响运行)
以上文字来源于龙豪软件（www.) |
| |
|
上面的保密方式我是不敢用的,版本管理困难呀,我记得在2003的firebird年会资料上就有人说过这个招了,但没人敢用.
vga,我不知道你会不会破解sql server的sa密码?如果会你就把他公布出来，让我们学习下我是不会的。不过我是很容易把ib/fb的sysdb密码破解的，这个方法很多都会的。要比功能的强大与全面、安全、易用.ib/fb是比不过sql server的（大家别吐口水呀）,不过ib/fb也有他的特色。反正是白菜、萝卜各有爱。能满足客户需要就是我们标准了
|
| |
|
版本管理是怎么回事？？
要是修改了存储过程，用新的存储过程replace create，然后再清除源码不行吗？？
所谓存储过程版本管理的概念,只是一个引用的概念而已, 意思是, 如果已经正式发行了的软件(已经交付用户使用了), 因某种原因升级时, 可能用户那里的数据库存储过程也需要更新, 那么就需要你在程序里写相关的专用代码来解决这个问题.
我目前的解决方案其实就是将开发时的新的存储过程代码,导出并加密
然后在相应程序的模块中解密导入,重编译, 然后,删除源代码
可能有更好的办法(或许可以省略加解密过程, 直接导出导入二进制代码,呵呵), 但目前我不知道,学习中...
我也在学习中啊,在用户那儿再编译, 确实不是好的解决方法吧,所以那时我还是不太肯定 不过今天提出的问题仔细一看,好像还真很简单, 可以直接利用RDB$PROCEDURE_BLR字段的,哈哈
|
 |
PROCEDURE_BLR字段是什么类型的？
可以直接Update么？？等你的测试结果。
PROCEDURE_BLR字段是BLOB，嗯，原来如此
|
|
