>I see, Jim.
>
>So by that logic you could really start a new system with all of your tables "pre-generated" with the estimated maximum number of DELETED records each and with PKs assigned as needed (say with negative numbers, just so as not to use up the more normal (positive) surrogates).
>
>That way you could not only eliminate the need for the weekend defrag but you would also have as consistent performance as possible for the life of the app.
>
>Cheers,
>
>Jim N
>

Jim,

Howdy... Some folks I've known who have extremely high volume data input systems (30-50,000 records per day) will typically do exactly what you suggest; pre-load the table with pre-assigned IDs. All they then do is have a logical flag along the order of "Active" or something like that and when they want to add a new record they get a positive lock, verify the lock, flip the Active flag and then return the PF ID. Pretty simple actually.

The thing is is that this kind of suystem would NEVER be used for day to day operations. It's just a collection point. From there you have robot processes running on other computers that massage the data into other tables and so forth. When extracting or 'massaging' the table this is where you'd want to return the record to Available status. It's a table like this that would be my candidate for the COPY TO scenario.

By granularizing the collection point vis a vis the actual work you get a lot of mileage and since that collection point table has such a specifically designed function in life it can then deal with the occassional bit of internal fragmentation.

Dealing with BIG chunks 'O Data require different strategies IMO.

Best,