在pf加上key以及unique的缺点？

mamei

请大家发表自己的观点！

我个人倾向于pf不加key以及unique

在lf里实现！

紫衫威龙

支持你的观点：但也有个别
分析如下：
1、当物理文件数据过大时，在新生成一条数据后，因为物理文件是有键字，那么需要对数据进行重新排序，从效率上讲是有些问题，但如果没有键字，则不存在该问题。
2、程序在处理过程中或者sql进行删除数据时，会有一定的记录空间需要重新整理，这时重整数据库的时候效率上会快点
3、但对于一些数据库，其使用频率很低，并且数据量不大时，可以不用考虑如上问题时，可以在物理文件中直接定义键字，

george251

这个是随业务的吧

passthru

我较早时间在我的blog写过文《项目中不能PF带key》，http://blog.chinaunix.net/u1/46034/showart_1963975.html

franliu

回复 1# mamei


1) 最近写入物理文件记录的位置根物理文件有没有使用键一点关系也没有。如果是新文件，或者没有已经被删除的纪录，或者有删除的纪录但是选择不利用删除纪录的空间，最新写入的纪录总是在文件的最后面。

2）用rpg读该文件，如果有键，f表里面有"k",那么读出来的次序就使用键。如果f表没有"k",或者用dsppfm, query, sql读出，读出来的次序是写进去的物理次序。

3）物理文件有键，就是说排序的b+ tree 与物理文件合二为一。物理文件没有键，而lf有键，b+ tree就在lf里面。

4）物理文件没有键，lf有键，写入物理文件时系统照样要修改lf中的b+ tree, 只是有时可以让这个修改延时一下而已。多数应用系统不允许这种延时。

qingzhou

优化索引对提高运行效率也很关键.

huangxkst

回复 1# mamei


    个人经验啊！我开发过的项目基本上pf都没有key，需要就添加相关的lf，让lf带key，但是也不会一味的添加lf，因为lf多了会占用存储空间，影响程序的执行效率。

insmile

和楼上的一样，没有遇到过PF带key的，都是LF有key；
开发中都是使用LF来读取，保存数据，用key定位