Mongodb – Structuring change history data in MongoDB / NoSQL

cosmos dbmongodbnosql

I have a Chart on which I need to track changes; the Chart has several properties. A Chart also has a long list of items.

So in C#, my Chart object looks like this:

public class Chart {
    public int Id { get; set; }
    public string Title { get; set; }
    ...
    public List<ChartItem> Items { get; set; }
}

Or in JSON, my Chart looks like this (I wrote this JSON by hand, so it could be wrong):

{
    "Id": 1,
    "Title": "Test Chart",
    "Items": [
        {
            "Id": 222,
            "Title": "Test Item",
            "Price": 112.34
        }
    ]
}

So my question is as follows:

Should I log an entire chart with all the items as a single document, every time there is a change? (Although I read there may be a limit on document size, so this could be a problem.)

OR

Should I log Chart changes as one type of document and Chart Item changes as a separate type of document? This would allow me to store changes to chart items as a single "line item" document without having to save the entire Chart every time there is a change to a single chart item.

OR

Is there a better way?

Best Answer

As per @DANIEL WATROUS Blog here The size of documents and the frequency with which they are changed must factor in to the retention of historical data.

Should I log an entire chart with all the items as a single document, every time there is a change? (Although I read there may be a limit on document size, so this could be a problem.)

As per your JSON code

{
    {"Id": 1},
    {"Title": "Test Chart"},
    {"Items": [
        {
            "Id": 222,
            "Title": "Test Item",
            "Price": 112.34
        }
    ]
}}

As MongoDB BOLhere The maximum BSON document size is 16 megabytes.

Each document in MongoDB has a specifically allocated size when it is created. Updates that increase the size of the document must allocate a new document large enough to accommodate the updated document on disk and move the document. This can be an expensive operation to perform, especially at high volume.

Should I log Chart changes as one type of document and Chart Item changes as a separate type of document? This would allow me to store changes to chart items as a single "line item" document without having to save the entire Chart every time there is a change to a single chart item.

There are a few options when it comes to dealing with uniquely identifying items data. One is to calculate a unique value at the time an object is placed in history. This could be a combination of the top level object ID and a sequential version number. Another is to generate a hash when the object is loaded. The problem with the second approach is that queries for specific date objects become more complex.

For your further ref here

Related Question