Portal And ArcSDE Geodatabase: Feature Datasets or Not

Question

We recently had a health check with an Esri representative, to look at our Portal system. After looking at our ArcSDE enterprise geodatabase she said it was organized very well with everything put into its appropriate feature dataset. However, she then proceeded to tell me that she does not place feature classes inside feature datasets in cases such as ours, where we use feature layers in a federated server but DON'T use the data store. She stated that either method works, but she prefers not to put them in feature datasets in cases like ours because how the published features access the database.

We are moving from a test environment to a production environment, and I will be replicating our data over. Is it best practices not to put data into feature datasets and have them at the root level, will this cause issues with version edits, will it provide a benefit or ruin or data organization scheme?

-Portal - Federated Not Using the Data Store -Version 10.6.1 -Feature Layers are published and reference the enterprise geodatabase and are NOT hosted

Answer 1

The biggest advantage I have found with feature datasets is not so much the organization per se - but the management capabilities you can leverage. We have different users editing different layers, and if I need to change permissions or Register / Unregister as Versioned - then all I need to do is perform those tasks at the feature dataset level instead of performing them one-by-one. The thematic grouping is really an afterthought.

If you're using a multi-tenant RDBMS such as Postgres or SQL Server - then you also have the option of just splitting things out into multiple databases... but I'm guessing this is a purpose-built environment for your needs and this would mean changing quite a bit.

I do know that in Portal and ArcGIS Online you can't create feature datasets like you can in an SDE environment - everything's pretty flat. So maybe Portal isn't designed to work with them. So that may be where the concern is coming from - that the client application (Portal) isn't built to work with that kind of data structure.