Enterprise ArcSDE Object Limit???

[JerryGarcia]

What is the maximum number of tables/feature classes for an Enterprise GDB? Is there a similar reference for ArcSDE using SQL Server?  http://resources.arcgis.com/en/help/main/10.2/index.html#//018s00000002000000 This is from Microsoft: https://technet.microsoft.com/en-us/library/aa933149%28v=sql.80%29.aspx Thanks!

[VinceAngelo]

The system would be unusable long before you hit the table maximums (5.0e+05 tables, vice 2.1e+10 limit), so it doesn't really much matter.

- V

[JerryGarcia]

Thanks for your reply. Is there any online reference to maximum "usable" limits? At what limit will people run into problems? Thanks!

[VinceAngelo]

None that I know of. Had a user on a beefy box with 100k tables -- took 20-25 minutes to log in.

Databases are about rows, not tables.  The tables should be kept as few as possible to prevent the high cost of inventory queries on the catalog.

- V

[JerryGarcia]

Yes, we have over 100k tables based on an implementation mainly due to security requirements (no row level security).  It takes a long time to connect to GDB and it does not fully compress.  We are in the process of migrating to a more manageable number of tables and implementing an SOI to secure GIS services.  I need to know if there are any published or non-published limits to the number of GDB objects.  I was hoping this may help us determine before we hit the threshold or if we have already passed it. Thanks.

[VinceAngelo]

Intialization time and compression failure are independent issues (the latter indicating geodatabase corruption).

I wouldn't recommend having more than 1000 tables, and 100 would be better.  I can't imagine a business case for 100k tables. These limits are partially geodatabase, but mostly due to the the database cost of listing and permission requests against the RDBMS.  Having a pretty UI box with a bunch of icons describing the table contents can be ruinously expensive, but you're not going to get a published source for worst case scenarios.

- V

[JerryGarcia]

Thanks.  What strategy would you recommend to implement row level security using Microsoft SQL Server with ArcSDE?

[VinceAngelo]

ArcSDE is just a protocol for accessing spatial data from ArcGIS.  Nothing in the API addresses security implementation (besides supporting GRANT requests as a pass-through to the RDBMS).  You certainly can't implement row-level security in ArcGIS, though it may honor whatever the database provides..

- V

[JerryGarcia]

The challenge we are facing is to implement feature level security, but this is not supported at the database level, and historically, at the GIS service level (or this has been very difficult).  We intend to implement custom logic at the web or GIS server tier to implement security and enforce complex workflows for editing the GIS data; consolidate our features in the GDB. Overall, there are no published limits to objects in an Enterprise GDB like there are for FGDB.

[VinceAngelo]

It would probably be easier to leverage an RDBMS that does support row-level security.

There are probably no published limits because it is not possible to get anywhere near the database limits, and the databases all publish their own limits.  The closest ArcSDE has to a limit is 2^31-2 logical tables, and the databases pretty much have 2^31-1 physical table limits, so you'd be hard pressed to get within an order of magnitude of the Esri limit.  The effective database limits are several orders of magnitude less, so the point is moot.

- V