Changing a coded Domain to no codes

Question

If we have coded domains in the geodatabase model, what are any disadvantages to changing the codes to the Description. For example:

Existing Coded Domain:

Code, Description 
1, Single Family Dwelling 
2, Multi Family Dwelling 
3, No Tenants

OR

Code, Description 
5200, Concrete 
5201, Steel 
5175, Copper 

New Coded Domain with Code and Description matching:

Code, Description 
Single Family Dwelling, Single Family Dwelling 
Multi Family Dwelling, Multi Family Dwelling 
No Tenants, No Tenants 

OR

Code, Description 
Concrete, Concrete 
Steel, Steel 
Copper, Copper

• Kirk Kuykendall: please elaborate, perhaps list the codes and their values in a tabular format showing what they are now and what they will look like after the proposed changes.

Answer 1

Domains restrict the entry of incorrect data into the database by providing a selectable value as against against user entered value.

Code is something which has more significance for ArcGIS, and the description part is for the humans using the system. Having said that, I don't see any disadvantage of changing the code to a more elaborate description. I think it's a matter of choice, as it will not affect the system behavior.

Hope it helps...!

• Stephen Lead: I know you asked specifically for DISADVANTAGES, but an advantage is that when exporting to a file format which doesn't support domains, your values will still be usable. Eg, you'll see "concrete" rather than "5200"
• Justin: That is the advantage that we are targeting. I am considering if internally the database passing around the number "1" is faster than passing around a 20 character string.
• Kirk Kuykendall: @Stephen I thought there was something in arctoolbox that would export with option of replacing coded values with descriptions, no?

Answer 2

When situation where integer or float coded domains have a big advantage is when your domain is also used as a calculation coefficients or constants. For example, if your coded domain was representing a network component, the float code could be the travel cost value of that component. This would eliminate an entire column from the table, and ensure that when the component type was changed, the component cost was automatically changed with it.

There are also some very interesting manipulations you can do with integer coded domains that you cannot do with text coded domains. As an example, I have a domain for siren maintenance. 0 is in good working order 1 needs a type 1 repair 2 needs a type 2 repair 4 no longer rotates 8 has blown out drivers 16 is dead A siren can have any combination of status, so a siren might be dead and need a type 2 repair, a type 1 repair, and no longer rotate. So, I have status 23: Dead sirens. Does not Rotate. Needs Type 1 and Type 2 Repair. I have 32 different statuses possible in all.

So, say a technician gives me a list of 35 sirens than need a type 1 repair. These sirens could already have any of the 32 statuses on them. If they already need a type 1, I make no change. If they are already in another status, I need to add type 1 repair to their status. If this was a text coded status, I would have to inspect each one and set their status accordingly; or use a series of 16 different select statements and value calculations (using precise strings even for the calculations).

But this is an integer coded status. So, I select the 35 sirens. I reselect for Status % 2 = 0 (they are not currently in type 1 status). Then, I calculate their status value to Status + 1 (add type 1 status). And I am done.

Answer 3

Technically, there may be a slight disadvantage in speed if the descriptions are long, but I don't think anyone would notice it and the advantages of being able to read it descriptively may outweigh the disadvantages.

The only other disadvantage I can see is that you may have to modify your database fields to accommodate the new descriptive text. Either from numeric to string, or from a smaller string to larger string field.