Quick Version: Is it more efficient, in terms of database performance, to have multiple separate temporary feature classes or one feature class that you repeatedly empty out and fill?

I am working with ArcGIS 10.1, Windows 7, using personal geodatabases.

I have a python toolbox tool that selects survey cells based on their proximity to a seed-cell. Once a boundary is determined, based on distance from the last selected set of cells, the final selected set is buffered to form the boundary. I have been using a single feature class (BoundaryHopper)to hold the output of the buffer and then appending that output to a second feature class that holds all the boundaries for a project (DerivedBoundaries). BoundaryHopper would be emptied out at the beginning of each loop iteration to avoid repeatedly appending the same boundaries to DerivedBoundaries ]

Recently I switched the tool over to using separate outputs for each buffer output (TempBoundary1,2,3...) and appending each individual feature class to DerivedBoundaries. That solved some issues I was having from trying to overwrite the same feature class all the time.

So, my question is: Are there any significant performance benefits of one technique over the other? Does one technique create less 'bloat' in the database or result in faster processing?

Any particular reason you're using .mdb and not .gdb?
–
MLowryFeb 14 '13 at 16:33

.mdb because I use the tables as data sources for a mail-merge to build summary packets for each boundary. The .gdb makes it harder to do that, so I just use the access format that is Word-friendly.
–
KevinFeb 14 '13 at 17:21

It's an interesting question, but unless you're experiencing a performance problem -- the pragmatic programmer would say you're done. Theoretically, a database table is meant to repeatedly handle repeated CRUD operations (even Access) and using temporary tables mildly violates normalization where you want to minimize redundancy -- given the caveat that a database is properly configured (particularly sizing, indexes and logs) and maintained.
–
awesomoFeb 14 '13 at 23:30

At this point I'll take a pragmatic solution over an optimized one! Thanks for the input, I hadn't thought about the normalization issue but for now, it works, I guess I'll stop trying to fix it!
–
KevinFeb 15 '13 at 15:14