Use SDE table as Domain Table

06-09-2010 06:23 PM
Status: Open
Labels (1)
New Contributor III

Rather than storing Domain Values in Binary or XML form within the sde.domain table, allow users to use the values of an SDE Table to propogate the Domain values.  This would allow for standard normalization on databases and eliminate redundancy of Domains stored over several GeoDatabases.

Tags (2)
Please oh please make it so. Domains can serve more purposes than simply limiting data entry. It can also be used to resolve opaque foreign-key values to something that people can read and make sense of. Especially if this suggestion is implemented.
Yes please make it so. It is ridiculous to deal with domain management tools or add ins to perform the simplest of tasks... (sort domains)

Better yet provide a command that creates a view thereby allowing the admin to sort the view as desired. 

It is a really fun having to explain to an Applications Manager who knows nothing about ArcGIS that their highly normalized database will have to be redundantly converted into the geodatabase using properietary arctoolbox/arcpy commands. 

Domains as tables or views just makes sense and fits into the majority of the database world. 

I never understood why ArcGIS uses domains when it could just use tables from the underlying database. If your geodatabase is built on top of Oracle, then you should be able to just choose which table/field is the appropriate "domain" for the field you are creating. In this way, when you update the Oracle table in some other app, the changes can be automatically applied to the geodatabase (using versioning, etc. when necessary). The fact that ArcGIS uses domains means that ESRI now has to build all these tools in order to edit the domains and it's very difficult for other apps to have access to that data (even read access, nevermind write access).

Agree. We all implement relational databases for a reason... You should see te faces of the database managers when I explain their relational database with normalized tables does not benefit the geodatabase much as we have to build tools to convert and maintain domain tables using toolboxes yet even these are lacking useful tools such as sort or reorder values. The geodatabase should use more relational design for its functionality. This might the same as this idea here, so make sure you vote for both.

Totaly agree. And not only a lookup for domainvalues would be nice but also use the relational power of the DBMS. ArcGIS support subtypes to generate domain lookups specific for a choice you make. Why not make this functionality go deeper. Domainvalues with relates to domainvalues and so on. You get a kind of tree choicelist through domain values. Eventualy you get an master/detail lookup for domain values.
It's obvious.  As Nike would say, just do it!
Yes, please!
Ditto on both comments, so far.  I thought of those things the first time I saw this issue in the ESRI Geodatabase many years ago.  This is such a no-brainer.  Why did ESRI do it the hard way?

How come this is not even "Under Consideration"?


In our SQL/SDE database we've made physical tables to store domain values in so the data can be used outside of ArcGIS.  This was a great idea 6 years ago and still a great idea today!


Yes, oh yes. I do export my domains often to gdb tables so I can: document them through reports, check data against domains, compare databases, join them to dirty data to clean up values.