Geodatabases - How many to create?

3445
7
Jump to solution
11-12-2014 07:44 AM
Highlighted
Occasional Contributor II

Hello,

 

I have approximately 60 shapefile I use. As of right now, they are all in one geodatabase.  I was wondering if there is a rule of thumb for when to create a new geodatabae?

 

Within my one geodatabase, I have multiple feature classes that could be categorized into something completely different.  For example, I have fiber optics within my geodatabase that also contains the downguy locations for utility poles.

 

Should I continue to keep everything in one geodatabase or start to create multiple ones and grouping the feature classes within those?

 

 

 

Thank you for your advice!

Reply
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Esri Frequent Contributor

Hi Kenric,

If you are using shapefiles, then they are stored outside of a geodatabase.

There is no "rule of thumb" for when to create a new geodatabase to store your data. It depends on many different factors (too many to list here).

Here are the limitations for both file geodatabases and enterprise geodatabases:

File geodatabase limitations

Enterprise geodatabase limitations

Hopefully this gives you a starting point to go from. Based on only having 60 feature classes, I would say that a single geodatabase should be fine at this time.

-George

--- George T.

View solution in original post

Reply
0 Kudos
7 Replies
Highlighted
Esri Frequent Contributor

Hi Kenric,

If you are using shapefiles, then they are stored outside of a geodatabase.

There is no "rule of thumb" for when to create a new geodatabase to store your data. It depends on many different factors (too many to list here).

Here are the limitations for both file geodatabases and enterprise geodatabases:

File geodatabase limitations

Enterprise geodatabase limitations

Hopefully this gives you a starting point to go from. Based on only having 60 feature classes, I would say that a single geodatabase should be fine at this time.

-George

--- George T.

View solution in original post

Reply
0 Kudos
Highlighted
Occasional Contributor II

Thank you for getting back to me quickly.  I will look at this, but it seems like I am doing fine for now!

Reply
0 Kudos
Highlighted
Regular Contributor

If you have a bunch of related shapefiles, you could group them together inside a geodatabase using feature datasets.  This way you can better organize your data while storing everything inside 1 geodatabase

Steven

Reply
0 Kudos
Highlighted
Esri Esteemed Contributor

Except that this is not recommended practice.  Using feature datasets for "folder" organization hurts performance and makes simple feature classes much less simple.

- V

Reply
0 Kudos
Highlighted
Regular Contributor

How bad does it hurt performance?  I'm thinking about this from an enterprise geodatabase.  I put all my data inside feature datasets because its easier to manage permissions for 1 feature dataset rather than 50 feature classes.  Maybe this is a topic for another discussion.  Is their a best practice document out there for this?

Thanks,

Steven

Reply
0 Kudos
Highlighted
Esri Esteemed Contributor

As with all things GIS, the answer is "It depends."  I have seen performance crippled by thousands of feature datasets with dozens of feature classes in each.  Esri training classes make it quite clear that feature datasets exist for cooperative table management associated with geometric networks, topology, or feature linked annotation.  It's a common theme in these discussion threads as well.  I didn't find any specific "best practice document" but I did find this discussion in the old, old forums.

I would suggest that ease of administration should not be the goal in configuring  geodatabases.  Best practice for security in databases involves creating one or more database roles for each access paradigm needed ("browsers", "basemap editors", "primary data editors", etc), then granting the roles the appropriate permissions on the feature classes once, and granting users access to the roles.  In this way, adding a new user is still simple (grant them the appropriate roles), and you don't need to tie your tables into a monolithic access block.

- V

Reply
0 Kudos
Highlighted
Regular Contributor

Thanks for the information.

Steven

Reply
0 Kudos