Question

Assume the following scenario (with relational databases),

class Currency
{
long id;
String code;
String name;
}

class OrderGroup
{
long id;
Collection<Order> Orders;
}

class Order
{
long id;
long currency;
}

in the practical scenario there will be large number of Orders (with ever growing numbers). What would be the optimum way to convert this to support a document based db. There is a option to change the currency code and name and when it happens will it be updated automatically across all the orders if the currency is added as a child of order?

Was it helpful?

Solution

When modeling relational database in document databases, it helps if you think in DDD term "Aggregates" and think how changing the value of an object will be handled, e.g. the object is either an Enitty or a Value Object, so in this case if you want changes of Currency affect existing orders, currency is NOT a value object and you just put a reference to the Currency object used in Order, somehow like the Relational Model. Model it like this will work in RavenDb:

OrderGroup aggregate:

public class OrderGroup
{
    public int Id { get; set; }
    public IList<Order> Orders { get; set; }
}

public class Order
{
    public int Id { get; set; }
    public int Currency { get; set; }
}

Currency Entity:

public class Currency 
{
    public int Id { get; set; }
    public string Code { get; set; }
    public string Name { get; set; }
}

Note, however, that modelling it like this you'll need separate queries to fetch/update the related objects.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top