SDE or File Geodatabase

[RandyKreuziger]

How many ArcGIS Desktop users / readers can a file geodatabase realistically support?

Here's the reason why I'm asking this question.  Years ago we created a single SDE/SQL geodatabase as a container for corporate GIS layers at our agency.  These "library", as we call it contains over 250 feature classes and tables.  At any one time during the work week, we have 60 users and everything is read only.  As you can imagine it's getting harder and harder for users to find the layers they are looking for with this many gis layers.  I've now been asked to load several new layers that are designed for cartographic purposes.  I'd rather not mix these layer into our current library so I'm thinking that maybe we should just add a file geodatabase on the file system where everyone can get at it.  I hate the idea of creating feature datasets in SDE.  Other options?

We are running ArcGIS 10.2.2 on SQL Server 2012.

[ChrisDonohue__GISP]

In general, it depends on how many people will be accessing it, both to look at and edit.  If more than one person will be in the data at a time, then an enterprise geodatabase (SDE) is where you want to be.  While you can technically have more than one person in a File Geodatabase at a time, there will be lock issues and chances of data corruption.  And one cannot have two or more people in a File Geodatabase to edit at one time (though sounds like editing is not performed based on what you said).

As an alternative, I guess one could replicate the File Geodatabases to allow more access.  But I'd stay away from having more than one person in a File Geodatabase.

Chris Donohue, GISP

[RandyKreuziger]

The data is completely read only.

[JoshuaBixby]

Esri states that file geodatabases are for a "single user and small workgroups."  Although 60 users is probably pushing the limits of "small workgroups," this is read-only data, so I would say it is more grey than black & white.  The Types of geodatabases documentation provides some good information, e.g., "many readers or one writer per feature dataset, stand-alone feature class, or table. Concurrent use of any specific file eventually degrades for large numbers of readers."  How large is large?  Once again, 60 is more of a grey area, especially if all 60 aren't accessing the same feature classes at the same time.

File geodatabases were designed with multiple users in mind.  There can be multiple editors in a file geodatabase at the same time, just not editing the same feature class or data within the same feature dataset.  Having many users read the same data doesn't risk data corruption, it impairs the performance of data access.

Honestly, it seems like you have already answered your question.  Usability is important, you don't need to dig for technical limitations that may or may not exist. 

[Anonymous User]

As per your uses that users are accessing data read only then,

Please import layers in SDE and share as package or connection to users to use it and its faster than previous.

No data loss in this case take backup or data.
its one time process and future ....

[JoeBorgione]

I've always worked in a relatively small environment with respect to users and feature classes/tables, but have deployed SDE/Enterprise Databases since v 8.x.  My users though have read-write access to some of the feature classes and are physically located through out the valley.

That said, I recently took a part time gig with the county, and they have a 'public' access SDE along the dimensions you describe, with maybe with a larger user base.  They use feature data sets to organize the data.  At first glance I was thinking, 'Hmm... Feature data sets... Warning Will Rogers...'  I know feature data sets were not designed as a file management system, but for a read only database, it seems to work for them. 

In my primary postition (the smaller environment noted at the beginning)  I mangage the data in an Enterprise db as noted.  However, for specific uses (it's a 9-1-1 dispatch center)  I typically replicate oneway  to a FGBD.  Perhaps such an approach could be depolyed in your case where you have several FGDBs of different themes of data.  Depending on the level of sophisitcation of your users, they could replicate one way to thier own FGDB those feature classes and tables they typically use.  [ That would keep you out of the replica mamanagement business, and put it on them.]

If replication isn't an option, I've also created models, and subsequent python scripts that use a series of Delete Features followed by Appends to empty out exisiting local FGDB feature classes and then append back in 'fresh' data. These can be fired as batch jobs at night.

[ModyBuchbinder]

Hi Randy

If you already have a SDE/SQL database then you know how to do it and you have the license.

Why not open a few more databases on the same SQL and split all the layers between them by area/group of people or any other cretria.

Each user will connect to the schema that s/he needs and see a small list of layers.

[RebeccaStrauch__GISP]

I second Mody's advice on creating another SDE database on the SQL if you want/need to keep the functionality that is currently available in the enterprise SDE/SQL.  The licensing typically allows you to do this.  You would use the same (ArcGIS Server) license file to authorize these new databases.  That way you could separate them into logical database groups.  Of course the downside of this, if users need multiple databases, they will have to have multiple connection files tot he SDE.

Same could be said if setting up multiple FGDB.  Personally, I like FGDBs for user r/o access and keep the SDE for editing master files.

Another downside is this could cause "broken links" in MXDs that the users use.  Although not perfect, I have a tool that can inventory and can update broken links.  FWIW /blogs/myAlaskaGIS/2015/08/31/python-addin-for-data-inventory-and-broken-link-repair?sr=search&searc...‌