Basically I want something like Dictionary<Tkey1, TKey2, TValue>, but not (as I've seen here in other question) with the keys in AND, but in OR. To better explain: I want to be able to find an element in the dictionary providing just one of the keys, not both.

I also think we should consider thread-safety and the ability to easily scale to a Dictionary<Tkey1, TKey2, TKeyN, TValue> solution...

Does this guarantee that the insider key is unique? Doesn't seem to me it does...
–
sergiolFeb 26 '12 at 14:53

assume that you are going to search where val <= key1 and val >= key2 so how would this solution work ?
–
MonsterMMORPGDec 23 '12 at 3:58

2

@MonsterMMORPG, dictionaries are not for doing inequality searches like that. It sounds to me like you would be best off to use a database, but if you want help you should post a separate question.
–
tsterJan 4 '13 at 18:15

It is a confusion with c++ multi_index which allows most of sensible indexes (sorted, unsorted, unique, sequence)
–
fantastoryFeb 17 at 10:17

So you want a multi-index dictionary, supports lookups based on any key, and supports extensions to multiple keys?

Maybe you're thinking of the wrong data structure, try a KD-Tree instead. An immutable KD-tree would satisfy the thread-safety requirement.

KD-trees have some major advantages over the naive Dictionary{Key1, Dictionary{Key2, Value}} approach, namely that you can search for all fields based on Key2 without knowing Key1. Additionally, KD-trees allow you to search for keys which are near some other key. For example, dating sites classify people into dozens of groups (smoker/non-smoker, gender, religion, lifestyle, age, height), then return nearest neighbors based on your query.

KD-trees are certainly useful for partitioning 2D points into planes (makes it easy to test for nearest neighbors), but you the dimensions of your tree can be as abstract as you want. The canonical example is a dating site which matches people up on multiple "levels of compatibility": smoker/non-smoker, preferred gender, preferred religion, vegetarian/non-vegetarian, preferred age range, preferred height, political orientation, etc. Naive algorithms in SQL can find matches, but the natural way to detect nearest neighbors (i.e. compatible spouses) uses a kd-tree.
–
JulietOct 1 '09 at 15:31

Very Intersting. Note, though, that the c# version is only implemented for double keys.
–
Ohad SchneiderAug 29 '11 at 9:52

I'm going to go out on a limb here and appear stupid, but you could just roll your own Dictionary based on two dictionaries. It wouldn't be too terribly difficult to write (even with locking mechanisms to ensure thread safety). I mean, there's plenty of examples out there where you can use an index or a key to access a collection. (Such as Session)

Conversely, if your multiple indexes are of the same type, you could just add the same item multiple times.

Dictionary will support something with a GUID index, as well as a simple name index "Joe" - you have to remember to add the item twice.

Count is only a ?challenge? for the second implementation where you're forced to halve it to obtain the real number. ... Deleting would be inefficient in either scenario, as you would be forced to traverse the Values collection to find the right entry to remove.
–
JustLorenOct 1 '09 at 16:17

If both keys are the same type, this method is not terrible. For different types, it's going to have issues.
–
Steven SuditOct 1 '09 at 15:24

The biggest issue this approach might pose is that it doesn't enforce the caller adding a second key (for the same value). While this may or may not be advantageous, it makes it a totally different beast.
–
nawfalJan 12 '14 at 15:20

Did you consider holding two dictionaries, one for each key? Adding an item would add it to both.

Removal means removing from both dictionaries too, and requires both keys. To remove with just one key, the item would have to store both keys. If it doesn't already hold both keys, you could wrap it in a container object that holds both keys and the item.

yes, in the end I think tster's is the best
–
MatteoSpOct 1 '09 at 15:39

1

Chad, the data isn't actually duplicated. As for not being able to scale, nothing stops you from chaining them in a loop, allowing an arbitrary number of key types. <A,<B,O>>, <B,<C,O>>, <C,<D,O>>, <D,<A,O>>
–
Steven SuditOct 1 '09 at 23:17