I've always preferred using SQL logins with data owner privileges as my organizational pattern in an enterprise GDB. That way the name of the SQL logins is used an alphabetical organization tool within the name of the layer.
Example: Several SQL Logins (FEMA, PublicWorks, Cadastral, Coastal, EmergencyServices).
Data would be named: GDBNAME.EmergencyServices.FireStations
And so on.
My question is, I started to take a look at ESRI's local government model gdb schema, and everything is organized in feature datasets. This is confusing to me.
I've always used feature datasets for feature classes that were truly related, for instance, terrain datasets, network datasets, parcel fabric, data with shared topological rulesets.
I've avoided using datasets as my organizational pattern mainly to avoid unnecessary schema locks on an entire dataset when a user is accessing one feature class within.
Have gdb organizational standards changed? Can someone more knowledgeable than me please explain this me so I can understand and try adapting this practice into my own work? I like the idea of the Government Model but need justifying as to why it was organized this way.
Any help is appreciated,
> ... I've always used feature datasets for feature classes that were truly related, for instance, terrain datasets, network datasets, parcel fabric, data with shared topological rulesets. ... I've avoided using datasets as my organizational pattern mainly to avoid unnecessary schema locks on an entire dataset when a user is accessing one feature class within.
I completely agree with your logic and statements above. As you said, a feature dataset is a collection of related feature classes that share a common coordinate system and they are generally used to spatially integrate related feature classes. However, I suppose that while it is technically possible to use a feature dataset for organizational purposes within a geodatabase, I don't think it is necessarily a best practice - from a technical persecptive.
I am not familiar with the Esri Local Government Model GDB schema - but I suppose they decided to use a feature dataset to aggregate feature classes thematically.
Hope this helps,
Yes, this is on par with my thinking. The Local Government Model GDB schema uses feature datasets as "folders". There isn't a single feature class in the GDB that is not a part of a dataset. I understand ESRI is doing this for an "all-encompassing" organizational pattern that can easily be plugged into any system. ESRI can't design a schema to fit every municipalities unique infrastructure for organizing feature classes, so they had to use feature datasets as "folders" and that would work more universally. I understand the process, I don't like it, but I understand.
Nick I feel your pain; recently an agency I contract to had me examine and deploy the LGIM. I scratched my head for a couple of weeks and made this post to the forum:
Best of luck
Thanks for the solace. How did you go about handling your situation? Just adding additional fields? I think LGM and it's accompanying map and app templates can still function when additional fields are added. Things start to break when names of feature classes are changed or when fields that are queried, are deleted. The addition of new fields shouldn't screw things up too bad. I don't think at least?
Added a couple, dropped a couple, tweaked a couple; just enough to fit the business model. I don't think ESRI intended it to be a one size fits all. That just won't work. If you stick with the feature class naming conventions, yes, you should be good to go. The deployment I worked on included using the Attribute Assistant, of which I am big fan. Its got couple hicups still, but by enlarge, its a handy tool to have.