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.
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.
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!
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.....
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.
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?
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.
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.
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..?
