This could have been the shortest post I ever have written, since the question could be answered with a simple one liner:
There are no tweaks
The whole point with SisoDb is making it simple and performant out of the box. It will never be targetting multitudes of different scenarios craving needs for adoptions to perform in each scenario.
With that said, there are things you should take in to thoughts.
Effectively work with references between documents
A document/structur has no relations. Everything included in it will get serialized and stored. The root is indicated by adding this one member public Guid|int SisoId { get; set;} to it, saying this is a document and I want to be able to store it. You can of course let your document contain other complex types/classes both with or without the SisoId member. But there’s a huge difference.
Given an Order:
public class Order
{
public Guid SisoId { get; set; }
}
If I add some simple attributes, it’s easy to understand that these will belong to the document.
public class Order
{
public Guid SisoId { get; set; }
public string OrderNo { get; set; }
public DateTime CreatedAt { get; set; }
public DateTime? ShippedAt { get; set; }
}
But what if I want a Customer linked to my Order? First, look at the Order as a pile of documents with the title “Order”. When writing a document and you want to reference someone elses writings, you put a reference to it by providing information where to find it, using e.g footnotes. The same thing goes here. Include CustomerId in the Order.
public class Order
{
...
public Guid CustomerId { get; set; }
...
}
public class Customer
{
public Guid SisoId { get; set; }
public string CustomerNo { get; set; }
...
...
}
Now you have made a connection saying: “My Order documents can point to Customer documents”. What If I want to have a Customer instance in the Order, since I don’t always might want to fire of new queries to fetch a Customer for a certain Order. Easy, just add a property for the Customer.
public class Order
{
...
public Guid CustomerId
{
get { return Customer.SisoId; }
private set { Customer.CustomerId = value; }
}
public Customer Customer { get; set; }
public Order()
{
Customer = new Customer();
}
}
Now, when you store a Order document, Customer will not be stored, since SisoDb will know that Customer is a document living on it’s own, since it has the member public Guid SisoId { get; set; }. The CustomerId will get stored, and this can be used when you are querying orders. What you then can do is to say: “Hey, load Orders and include Customers.”
using(var uow = db.CreateUnitOfWork())
{
var orders = uow.Query<Order>(q =>
q.Include<Customer>(order => order.CustomerId));
}
What SisoDb will do is to in the same query and JSON-result incorporate the JSON of the included documents/structures. Hence you will not get any extra roundtrips and you have gotten yourself a fully loaded Order. More information.
Control what to make Queryable
By default every simple property is extracted from your document/structures and made queryable in SisoDb. This is of course something that you can control and if you have a deep graph with lots of members but you only query on a few of them, you will get better performance by only making these fields queryable, which means that the Indexes table for that document type will get smaller. More information.
db.StructureSchemas.StructureTypeFactory.Configurations.NewForType<Customer>().OnlyIndexThis(c => c.CustomerNo);
That’s it for now. Now I’m going to tweak SisoDb for you, so you don’t have to 
//Daniel
