Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?


share|improve this question
Any particular reason you're using .mdb and not .gdb? – MLowry Feb 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. – Kevin Feb 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. – awesomo Feb 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! – Kevin Feb 15 '13 at 15:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.