I usually create my LOVs in the following way:
- just to illustrate my question, let's imagine I need to create a LOV based on a table called COUNTRIES which presents a list of all countries around the world.
- to attend this purpose I create two fields: the 1st one has the LOV itself, and it will present the country code; the 2nd one is a read only field which will receive and display country name related to the country code (let's say 1 - USA, 2 - BRAZIL, 3 - GERMANY and so on).
- I know I can create non-enterable LOVs which presents the name and keeps the code, but sometimes an operator already know the code by heart and prefers typing it, which is faster than opening the LOV which requires a query being run against the database, and this might be noticeably slow;
- if I create two separated fields, one for LOV with codes and other for descriptions, it leads me to create a 3rd object - a PL/SQL dynamic action at the number field, returning the name which was already available at the same LOV (assuming that user is able to type the code at the number field) and it will at the same time verify if the typed code is valid (assuming there's nothing absurd like "-1" code).
I am dissatisfied with this approach, so I need to discuss the possibility to overcome it. I imagine users can either type the code or open the LOV - please notice that I know I could implement an intellisense with value placeholders at text fields but sometimes I'd rather be keeping a separated field with a LOV, especially when operators are being presented to a new APEX page and want to have a look at available values. I could also create PL/SQL database objects inside a package where LOV contents are unified but I would like to see new solutions for LOVs because I guess there could be better options out there.
Having better ideas, please help. If there are no other options than those described above, please tell me why.