在pf加上key以及unique的缺點(diǎn)？

mamei

請大家發(fā)表自己的觀點(diǎn)！

我個人傾向于pf不加key以及unique

在lf里實(shí)現(xiàn)！

紫衫威龍

支持你的觀點(diǎn)：但也有個別
分析如下：
1、當(dāng)物理文件數(shù)據(jù)過大時，在新生成一條數(shù)據(jù)后，因?yàn)槲锢砦募�是有鍵字，那么需要對數(shù)據(jù)進(jìn)行重新排序，從效率上講是有些問題，但如果沒有鍵字，則不存在該問題。
2、程序在處理過程中或者sql進(jìn)行刪除數(shù)據(jù)時，會有一定的記錄空間需要重新整理，這時重整數(shù)據(jù)庫的時候效率上會快點(diǎn)
3、但對于一些數(shù)據(jù)庫，其使用頻率很低，并且數(shù)據(jù)量不大時，可以不用考慮如上問題時，可以在物理文件中直接定義鍵字，

george251

這個是隨業(yè)務(wù)的吧

passthru

我較早時間在我的blog寫過文《項(xiàng)目中不能PF帶key》，http://blog.chinaunix.net/u1/46034/showart_1963975.html

franliu

回復(fù) 1# mamei


1) 最近寫入物理文件記錄的位置根物理文件有沒有使用鍵一點(diǎn)關(guān)系也沒有。如果是新文件，或者沒有已經(jīng)被刪除的紀(jì)錄，或者有刪除的紀(jì)錄但是選擇不利用刪除紀(jì)錄的空間，最新寫入的紀(jì)錄總是在文件的最后面。

2）用rpg讀該文件，如果有鍵，f表里面有"k",那么讀出來的次序就使用鍵。如果f表沒有"k",或者用dsppfm, query, sql讀出，讀出來的次序是寫進(jìn)去的物理次序。

3）物理文件有鍵，就是說排序的b+ tree 與物理文件合二為一。物理文件沒有鍵，而lf有鍵，b+ tree就在lf里面。

4）物理文件沒有鍵，lf有鍵，寫入物理文件時系統(tǒng)照樣要修改lf中的b+ tree, 只是有時可以讓這個修改延時一下而已。多數(shù)應(yīng)用系統(tǒng)不允許這種延時。

qingzhou

優(yōu)化索引對提高運(yùn)行效率也很關(guān)鍵.

huangxkst

回復(fù) 1# mamei


    個人經(jīng)驗(yàn)�。∥议_發(fā)過的項(xiàng)目基本上pf都沒有key，需要就添加相關(guān)的lf，讓lf帶key，但是也不會一味的添加lf，因?yàn)閘f多了會占用存儲空間，影響程序的執(zhí)行效率。

insmile

和樓上的一樣，沒有遇到過PF帶key的，都是LF有key；
開發(fā)中都是使用LF來讀取，保存數(shù)據(jù)，用key定位