Data Model

It is difficult to save the data without redundances, as there are some in the original data. As long as the LARCs are seen independently, this is no problem.

New Colors

New colors do not make for new IDs (i.e. approval codes) of coverings. Therefore, the approval code is not sufficient enough to distinct the validity of coverings without applying dates to covering colors.

Storing colors to every covering and color is redundancy galore.

Hence, the coverings are defined once, the colors are separated and connected with their LARC ids. So, the LARCs define the validity and the redundancy lies in the colors being connected to the same LARCs.

Coverings <-> LARCs

The LARCs are linked to the individual colors for an exact data model.

Expiration Dates

Some coverings have expiration dates in the list. This means, they will expire on the given date in contrast to the other coverings, that most likely will be valid after the expiration of the larc.

JSON as database

At the moment I find the readability of JSON more important than using a RDBMS, especially for the low number of datasets.

I am storing all data in one file, some JSON experts suggest separate files for relations. If this approach is better, we would just have to store the top objects as separate files.

Lists vs. Maps

Lists of elements are modeled as lists, not maps using the id as key.

Lists:

{
    "larcs": [
        {
            "id": 46",
            "filename": "LARC_46_B_2021"
        }
    ]
}

Maps:

{
    "larcs": {
        "46": {
            "filename": "LARC_46_B_2021"
        }
    }
}

Advantage: a list is a list, this eases the use in languages with weak object/map support.

Disadvantages: the automatic static id check of maps is missing. I find the map approach slightly more elegant.