SDE and organising Feature Classes & Feature Datsets

[timdunlevie]

Hi,

We are in the process of migrating to a SQL database with SDE.
I am new to SDE...
What I am trying to get my head around is how to "organise" all my feature classes from around the world in SDE (I've come from a file server environment).
Most (if not all) our feature classes don't require topological relationship, and therefore don't require a Feature Dataset.

So the question is, is it good practise to simply organise one big bin of feature classes in SDE and use a good naming convention to distinguish areas around the world where this data is associated to ?

I can then "sort" this data either as .lyr files, or as File geodatabases on the server for the users...

Thanks,
Tim

[VinceAngelo]

It's worst practice, if you will, to use feature datasets as folders to organize feature classes,
but there aren't a lot of attractive alternatives.

There are a number of possible ways to partition data that are considered "best practice":

• Into databases (if they'll never be used together [except as independent map layers],

and you're not using Oracle, which [until 12c] didn't support the concept)

• Using owners/schemas


• Using table names

So yes, you are certainly on the right track, but I would have you think about users and
databases as well.

- V

[timdunlevie]

It's worst practice, if you will, to use feature datasets as folders to organize feature classes,
but there aren't a lot of attractive alternatives.

There are a number of possible ways to partition data that are considered "best practice":

• Into databases (if they'll never be used together [except as independent map layers],

and you're not using Oracle, which [until 12c] didn't support the concept)

• Using owners/schemas


• Using table names

So yes, you are certainly on the right track, but I would have you think about users and
databases as well.

- V

thanks V.

yeah I want to steer away from Feature Datasets, so you have at least given me the green light to do this 🙂

I personally don't see a problem of having a large number of feature classes all in a "big bin"...as long as they are logically named.

When you say "using owners/schemas" do you refer to me only seeing data which I am the Admin owner of (there will be 2 owners of the SDE data, me - for my region of the world, and another - for their region of the world) ?

we have a SQL server.

thanks,
Tim

[VinceAngelo]

If you have global data, and regional data for two different continents, and they're at different
scales, so you can't easily overlay them without issues, then I'd recommend using different
databases, which would make them completely autonomous.  The regional folks would still
have access to the global data for scale-dependent mapping, but their focus would be in
their region.  Then you could create owners like transportation, basemap, power, water, etc
in all three databases to standardize the themes of data available, and then get clever in
the naming (to include scale and topology class, if you have room in 31 chars).

I don't have a problem with a huge pile of tables, but when I can, I like to make the
organization as clean as possible.

- V

[timdunlevie]

If you have global data, and regional data for two different continents, and they're at different
scales, so you can't easily overlay them without issues, then I'd recommend using different
databases, which would make them completely autonomous.  The regional folks would still
have access to the global data for scale-dependent mapping, but their focus would be in
their region.  Then you could create owners like transportation, basemap, power, water, etc
in all three databases to standardize the themes of data available, and then get clever in
the naming (to include scale and topology class, if you have room in 31 chars).

I don't have a problem with a huge pile of tables, but when I can, I like to make the
organization as clean as possible.

- V

Thanks V.

Although independent of one another (with regard to scale), the global data will still be relevant to the regional data.
I guess a further point, which I want to clarify, is if we did go with a huge pile of tables approach...it's then quite simple to serve the data in logical folders on a server either via .lyr files or file geodatabase for the people consuming the data ?

Thanks,
Tim

[MarcoBoeringa]

It's worst practice, if you will, to use feature datasets as folders to organize feature classes,
but there aren't a lot of attractive alternatives.

I have never understood why ESRI didn't devise a kind of "virtual folder" for organizing Feature Classes and Feature Datasets in - or on top of - its geodatabase model, allowing users to easily organize all of their FC's and FD's, and displaying it structured like that in the ArcGIS for Desktop user interfaces. How hard can it be to implement? It doesn't need to affect existing functionality, it just needs to be a virtual folder to group things.

As a consequence, by the lack of such a thing, people logically assume, and misuse, the Feature Dataset for it... (although not all misuses in this respect are a real issue, it all depends on the data and how it is being used).

[VinceAngelo]

Although independent of one another (with regard to scale), the global data will still be relevant to the regional data.

The important distinction is whether you will be doing overlay operations in SQL between the tables.
If you won't be doing theme-on-theme operations, then the location doesn't matter.

I guess a further point, which I want to clarify, is if we did go with a huge pile of tables approach...it's then quite simple to serve the data in logical folders on a server either via .lyr files or file geodatabase for the people consuming the data ?

I don't understand this part.  The data wouldn't get into file geodatabase without being put there,
and that part isn't always simple.  Why store the data twice, and have to deal with synchronization?

But yes, .lyr files can reference enterprise geodatabase data.

- V

[VinceAngelo]

How hard can it be to implement?

It's always risky to ask that question if you don't have the source in your lap.  I'd actually think
it pretty hard (caveat: I don't have the source in my lap either).  Changing the geodatbase XML
schema isn't a trivial activity, and then all the tools and UIs that reference objects would need
to be changed to suit.  I think it would be a worthwhile endeavor, but I wouldn't expect it to be
easy task.

As a consequence, by the lack of such a thing, people logically assume, and misuse,
the Feature Dataset for it.

Too true.

- V

[timdunlevie]

The important distinction is whether you will be doing overlay operations in SQL between the tables.
If you won't be doing theme-on-theme operations, then the location doesn't matter.



I don't understand this part.  The data wouldn't get into file geodatabase without being put there,
and that part isn't always simple.  Why store the data twice, and have to deal with synchronization?

But yes, .lyr files can reference enterprise geodatabase data.

- V

Cheers.
Yeah we may be doing overlay operations with global-scale data versus regional scale.

In regards to your other query, as I want to steer away from creating Feature Datasets to store Feature classes, I am thinking of having a big list of Feature Classes in the SQL database, then reference to them via a .lyr file which sits on my file server (sorted nicely into folders)....rather than having people connect directly to SDE to access the datasets.
So the only pain is to set up the file structure on the file server and create the .lyr files.

Thanks,
Tim

[MarcoBoeringa]

I am thinking of having a big list of Feature Classes in the SQL database, then reference to them via a .lyr file which sits on my file server (sorted nicely into folders)....rather than having people connect directly to SDE to access the datasets.
So the only pain is to set up the file structure on the file server and create the .lyr files.

There are other good reasons to not have all of your users access data directly, but through a well organized collection of layer (*.lyr) files:

- Ability to set a host of important display settings, like symbology, labelling (and reference scales for that), definition queries etc.
- Very important: set appropriate minimum and maximum display scales.

This second option is very important, it prevents users from accidentally accessing a huge layer (e.g. millions of records) entirely at full extent, causing a severe hit at the database level by needing to read the entire table.