Domains Best Practices

[RandyKreuziger]

Has anyone put together a best practices for creating and using domains?

[RandyKreuziger]

471 views and no responses so here's a specific case.

When needing to represent True / False or Yes / No which of the following examples is better from a geodatabase design point of view?

Our database architect hates the option on the right but when looking at the data using a non-esri tool using letters makes it easy to understand without needing to do a database join.

Store an integer      or   Store a string and use the first letter

0  - 'No'                              'N' - 'No'

1  - 'Yes'                             'Y' - 'Yes'

0  - 'False'                           'F' - 'False'

1  - 'True'                            'T' - 'True'

[TobiasFimpel1]

I would argue that coded value domains should in most cases be designed with code=description. So in your case, it would 'Yes'-'Yes', 'No'-'No'. From a computing point of view there are advantages to using integers like 0 and 1, and if it is a subtype field it needs to be an integer field as well. Those are valid arguments for integers.

However, it has been my experience that using code=description avoids a whole lot of oddities that you will otherwise keep running into again and again (e.g. Export to shapefile it is nice to end up with the actual values; ArcGIS Online drop down lists is nice to see the actual values consistently across apps and devices; ArcPad .axf tables is nice to see the actual values; Python cursors is nice to deal with the actual values; etc.... it juts saves you some headaches all across the board.)

If anyone has a different opinion I would be very interested in learning more.

[JordanDavis2]

Looking for best practices as well. 

I generally use code=description format, all text currently. Drop downs for shapefile attributes and survey123 tables are much easier.  I have tried using integers but found text is easier, especially when tables get exported to excel for our non-technical staff.

One case for using code != description: We have product codes that are not very human readable and they need to match a database we do not have access too. So the code is the complicated jumble of letters, description is the human friendly and easily readable one. We can still export our data or import theirs and run statistics on both sets as a whole.

[DavidLitke]

Is there much of a performance/storage space hit if the code is a relatively long text string instead of an integer?