Be careful about using Lists. The good thing about lists is that users can't enter the wrong value (like they can with String). Any time the EA is loaded, the entire back-end list must be loaded. This is true for all CRUD calls (including in the GUI) for which the EA can apply. If you build a very large list, it will inevitably run into performance issues.

EA's are worth approximately 0.1 objects in database utilization calculations. Be mindful of the “increase” in utilization this generates.

Maximum EA list size is 10,000 but NEVER go this high. 100 as a max is realistic. Every time an ENUM (list) EA is accessed, the system pulls the ENTIRE ENUM definition (meaning all entries) before performing the action to either match value to ID or to match ID to value (depending on read or write). This will slow the system down.

The reality of EA's is that they should be well thought out, well planned, and well prepared. The user should have internal documentation around their own EA's. They should consider how and when they're used, the objects types, the inheritance rules, etc. And really, they should do all of this BEFORE implementing the first EA (rarely happens this way).

One other note – EA's shouldn't be used for “data validation.” In other words, the user should perform data validation/integrity checking BEFORE making the API call to Infoblox; don't use an ENUM simply for data validation. They'll come to regret it.