idea Add ability to store feature classes and other geodatabase objects within a simple folder structure. in Data Management Ideas

Add ability to store feature classes and other geodatabase objects within a simple folder structure.

Anonymous User — Wed, 05 Oct 2022 16:46:35 GMT

Add a geodatabase feature that is a simple organization tool (e.g. folders) that doesn't add any functionality to the data or impose any restrictions like the feature dataset imposes.

Re: Add ability to store feature classes and other geodatabase objects within a simple folder structure.

MikeLong4 — Thu, 01 Apr 2010 02:30:11 GMT

I would like to see this as well. Too many people are using Feature Datasets as folders without knowing that's not what they are for. The Schematics Extension has this ability when storing the diagrams in the GDB.

Re: Add ability to store feature classes and other geodatabase objects within a simple folder structure.

LeoForetich_Jr — Mon, 21 Jun 2010 18:03:06 GMT

We have so many layers etc. that some users have started calling SDE the "data dumpster".

This is exactly how the original DOS operating system started out. There were no folders, and all files were stored in the single root directory. When users listed files, they saw every file name.

Which reminds me, the original DOS also restricted file names to 8 characters. While SDE allows more than 8, it is limited to the database table limits. There is no reason "layers" etc. could not be abstract synonyms which would allow 128+ characters, including spaces!

Re: Add ability to store feature classes and other geodatabase objects within a simple folder structure.

DavidWheelock — Wed, 14 Jul 2010 21:26:52 GMT

"Data dumpster" HOW TRUE! 🙂

ESRI: Please combine these into a single topic.

This idea is also here:
https://c.na1.visual.force.com/apex/ideaView?id=0873000000088oUAAQ
and here:
https://c.na1.visual.force.com/apex/ideaView?id=0873000000087Qz&mc=0

Let's promote this! I need it today. Forcing you to store all of your data at the "root" level is just senseless. I was told by ESRI that this was coming, but I haven't seen it yet. Is it there in 10?

I, too, was told by ESRI staff NOT to use feature datasets for this purpose, because of the issues described below. I do it anyway, but lately I've been running into the locking issue. GRRrrrrr.....

Re: Add ability to store feature classes and other geodatabase objects within a simple folder structure.

RobertRenner — Sun, 17 Oct 2010 16:07:26 GMT

If ESRI could provide this ability, I wouldn't have this problem:

https://c.na1.visual.force.com/apex/ideaView?id=087300000008G0I&returnUrl=%2Fapex%2FideaList%3Fc%3D09a300000004xET%26sort%3Drecent

Re: Add ability to store feature classes and other geodatabase objects within a simple folder structure.

EricPaitz — Mon, 25 Apr 2011 20:10:28 GMT

This idea has already been considered by ESRI. Implementing this idea can come with a price. In the case of an SDE Geodatabase that uses Oracle, SQL Server, etc a table name must be unique and the RDBMS does not have any type of logical container like a folder, so all of this would have to be created by ESRI and managed by SDE in its system tables. If you have a folder called Ohio and another folder called Utah and in each of these folders you have a Feature Class called Rivers this means to the RDBMS that you have two tables called Rivers which is not allowed. This is also true for Feature Dataset. SDE would have to totally take control of all the table names and use something like a GUID (or some other naming convention) for each table name so that SDE could create this “logical” container called a folder. This means it will look like you have a Feature Class called Rivers to ArcGIS but using the RDBMS tools you will never see a table called Rivers. This may be possible to implement using a File GDB because its structure is 100% created by ESRI and not limited by an RDBMS, but I suspect that ESRI wants to have that same user experience with any Geodatabase implementation. It’s a good idea but can be very difficult to implement.

Re: Add ability to store feature classes and other geodatabase objects within a simple folder structure.

JordynMitchell — Fri, 30 Dec 2011 21:50:21 GMT

it may not be necesary to be so complicated. Couldn't the "view" information be stored with the CLIENT in some kind of config file (which could be shared) rather than inside the database?

Re: Add ability to store feature classes and other geodatabase objects within a simple folder structure.

NikolausPruzsinszky1 — Thu, 29 Mar 2012 12:02:51 GMT

That' exactly what i need, especially for the rasters in my fGDB.

Re: Add ability to store feature classes and other geodatabase objects within a simple folder structure.

DuncanHornby — Mon, 22 Oct 2012 09:27:17 GMT

Some of my analyses can generate many tables (not featureclasses) and storing them within a geodatabase is a logical and sensible approach.

It has always frustrated me that I could not organize them better inside the geodatabase (personal/file). I would like to see a "folder" for tables inside the geodatabase and have no issue with the table names having to be unique.

Re: Add ability to store feature classes and other geodatabase objects within a simple folder structure.

GuyMadgwick — Mon, 12 Aug 2013 13:11:33 GMT

Being able to implement a sub-directory structure as well as a directory/folder structure to geodatabase features would further ease the organisation of layers in a geodatabase.

It seems strange that shapefiles can be organised this way but not any layers involving a DBMS like Oracle or SQL Server, even though the latter is the newer technology.

Without any adequate means of organising geodatabase features, finding a layer to add to a map can involve having to scroll through hundreds of irrelevant layers, made even more difficult from the fact that the "Add Data" dialog box cannot show very many layers at once, being so small and not resizable.

Re: Add ability to store feature classes and other geodatabase objects within a simple folder structure.

DavidKneen — Thu, 24 Apr 2014 10:13:01 GMT

Just got off the phone with ESRI Support who told me to stop using Feature Datasets to organise Feature Classes - Ironically the other link they sent me from the help file says that uses commonly do exactly what I was suggesting..?

http://resources.arcgis.com/en/help/main/10.2/index.html#//002300000001000000

So another vote for all of the above here.

Stop the misuse of feature datasets

Anonymous User — Thu, 23 Feb 2023 00:04:14 GMT

Given the widespread misuse of 'feature datasets' could ESRI consider creating a new database structure equivalent to adding a subfolder in windows?

e.g. geodatabase (right click)> New > feature class OR feature folder (bucket, compartment whatever you want to call it...) OR feature dataset OR rest of the options.

NB - feature class top of list!

Re: Stop the misuse of feature datasets - Status changed to: Needs Clarification

SSWoodward — Thu, 23 Feb 2023 00:06:30 GMT

Thanks for the Idea, @Anonymous User. It looks like this Idea may be a duplicate of one posted on the Data Management Exchange. I've linked it below. If you think it's similar, I'll merge them so your comments and kudos are added to it.

Link to Idea - Add Ability to Store Feature Classes and other ...

Re: Add ability to store feature classes and other geodatabase objects within a simple folder structure.

Anonymous User — Wed, 01 Mar 2023 22:34:21 GMT

Hi @SSWoodward - indeed it is! My apologies, I did look but I guess not deep enough 🙂 Great to see there is quite an appetite for it 🙂

Re: Add ability to store feature classes and other geodatabase objects within a simple folder structure.

Anonymous User — Wed, 01 Mar 2023 22:37:32 GMT

Whoah! that idea was 2010, and yet ESRI added create new Feature Dataset as the top choice in Catalog create new in ArcPRO? That is madness.

Re: Add ability to store feature classes and other geodatabase objects within a simple folder structure.

SSWoodward — Wed, 01 Mar 2023 23:45:56 GMT

Thanks for the confirmation @Anonymous User ,

One option for dataset organization is the Catalog Dataset, take a look and let us know if this is something that you find useful.

Link - An Overview of Catalog Datasets

Sub/Child datasets or Group datasets in Geodatabase/FGDB

User35488 — Thu, 20 Feb 2025 09:59:42 GMT

Allow to create sub/child datasets or Group datasets in Geodatabase/FGDB

Re: Sub/Child datasets or Group datasets in Geodatabase/FGDB

Kevin_MacLeod — Thu, 27 Feb 2025 19:09:07 GMT

Great idea. Here's the deal. Almost everyone in the REAL world uses Datasets as folders. Many folks do not know the implications of this, and are not aware that was not their original intent. They were for topology, networks and other complex functionality. They lock all FCs in them. However, we still use them like folders. Almost everyone does. Because what is the alternative? There isn't one. Hundreds of layers in a flat list is unwieldy.

When I asked the Data Management team leads at a UC sometime early last decade, they said " just use a different database for a different group of layers". With dozens of 'groups' of layers, like by jurisdiction or utility category etc, that won't work, to have dozens of SDE db connections. So we soldier on, with Datasets and their Locks. Hope they can create a concept of SDE database 'folders' that merely serve to organize visually. No locking, no need to include networks and topologies. Simply visual appearance. This should be very easy to code. And I love your idea of sub-folders. Allow infininite sub-directories.

Team Esri-- thoughts??