There are many different approaches to modeling with OrigoDb. We try to give you as much freedom as possible. There are just a few constraints:
Serializable(required for snapshots)
One of the core strengths of Origo is that you can choose the most appropriate data representation for your application. You can do object-oriented domain modeling, relational, key/value, graph, document, column store or whatever else you can think of. Wan’t a 4-dimensional array of Quark-objects? No problem.
Want automatic versioning, snapshots and lock-free concurrency? No problem, build your model using the new awesome immutable collection classes.
We often see people using domain specific object-oriented modeling with either an anemic model and fat transactions or a rich model with thin transactions:
You have to consider performance when choosing data structures. Analyzing data access patterns and estimated data volume will help you choose between dictionaries, lists, hashsets, queues, stacks, arrays etc
Traditional disk-based relational databases use B-trees for tables and indexes. B-trees provide a reasonable and balanced performance for all types of operations: seek, scan, insert, delete, etc.
SortedDictionary<K,V> are pretty good equivalents.