>>Typically, you seldom want to read a entire table, but only a part of it. In a OLTP environment with lots of writes (inserts) in different tables fragmentation naturally occurs in the first available clusters, causing fragmentation. For write purposes this is not any problem, and in fact it is the most effective manner to do inserts.
>
>"Some" (most ?) DBMS more or less manage their own space within "pre-allocated" database space, which may be further extended at run time.

But we don't know for sure that such schemes do not depend on fragmentation for optimizing performance, do we?

>
>"Fragmentation" is not necessarily a given in OLTP environments.
>
>For that matter, even DBF's could be "pre-allocated" and the (initial) empty space recycled if one was really concerned about fragmentation.

It could, but I think it gets a bit dicier when PKs are involved. Also, evidence suggests that the creation of such pre-allocated DBFs still have a good chance of being fragmented, unless extraordinary steps are taken.

I have just about finished some BASIC study of the issue and will have a thread today reporting my findings.

cheers