.NET container for two-way conversion data?

Question

I have conversion tables I need to contain in memory for fast access. Until now I used a simple Hashtable were the Key was the internal code, and the Value was an object holding the external code and other meta-data.

Now we need to have a reverse look-up, meaning to get the internal code based on the external code. I could only come up with the following options:

1. Have another container for this look-up, Hashtable containing only the internal code as Value to prevent more redundancy.
2. Use the same container I use now, and store those objects again now using the the external code as the Key (have a prefix to prevent collisions).
3. Don't pull data using Keys, but iterate through the Values contained under the same container to find the requested object ( O(n), same memory usage ).

The container is being lazy-loaded, so options 1&2 usually won't perform under the worst-case scenario.

Thoughts anyone? Please tell me there's some efficient container I could use for that, which I missed!

* EDIT *

Being a GC'd framework, and accepting the fact I'd have to have two conversion arrays (Dictionaries), would the following lines of code actually mean I stored only one object on memory, and then two pointers for it, under two different hashed-cells?

Dictionary<K1,V> forward;
Dictionary<K2,V> reverse;
//...    
void Add(V myObject)
{
    // myObject being the BLL object
    forward.Add(myObject.InternalCode, myObject);
    reverse.Add(myObject.ExternalCode, myObject);
}

Itamar.

Answer 1

Build a custom collection class that has two internal hashtables (Dictionarys), one in each direction.

  public BiHashTable<K, V>
  {
     private Dictionary<K, V> vals = new Dictionary<K, V>();
     private Dictionary<V, K> keys = new Dictionary<V, K>();
     public void Add(K key, V val)
     {
        vals.Add(key, val);
        keys.Add(val, key);
     }
     public K this[v val] { get { return keys[val]; } }
     public V this[K key] { get { return vals[key]; } }
     // etc... 
  }

NOTE: This will be problematic is both K and V are the same type, you need a different formulation then...

Answer 2

I rather use two instances of Dictionary<TKey, TValue>

It favors code readability

Are you sure this dictionary is a performance bottleneck?