Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add List<Metadata> to Organization model #12

Open
miguel-merlin opened this issue Nov 10, 2024 · 3 comments
Open

Add List<Metadata> to Organization model #12

miguel-merlin opened this issue Nov 10, 2024 · 3 comments

Comments

@miguel-merlin
Copy link
Member

Description

There is a one-to-many relationship between Organization and Metadata. We have two approaches to model this relationship.

Linked (Denormalized) Data

{
"id": "",
"name": "",
"alternate_name": "",
...,
"metadata": [
{
"id": "1",
"metadata-attribute": "",
},
{
"id": "2",
"metadata-attribute": "",
}
]
}

In essence, all the metadata objects are stored inside the metadata attribute of the Organization object. This is mainly used when we are trying to model one-to-one (not the case) relationships or one-to-few (I think this is the case).

Linked (Normalized) Data

Organizations collection

{
"id": "",
"name": "",
"alternate_name": "",
...,
"metadata": [1, 2]
}

Metadata collection

{
"id": "1",
"attribute": "",
...
},
{
"id": "2",
"attribute": "",
...
}

At least for the metadata attribute I would suggest going with Linked Denormalized relationships.

@ZhangTerrence
Copy link
Contributor

When I wrote the models, I did not include the foreign key attributes as they were inherently defined in a denormalized environment. For example, the metadata collection should have a resource_id attribute. However, should I include them just to match the HSDS schema reference and enable two-way references?

@miguel-merlin
Copy link
Member Author

Not necessarily for all attributes. Having a denormalized data and normalized really depends on the writes/reads done to the attribute. Denormalized data works for attributes that are read often, but not changed often. It models one-to-one and one-to-few. At least for the metadata which Im assuming is not written often, it would make sense that we store it inside the organization object.

@ZhangTerrence
Copy link
Contributor

I see, that does make sense since this database is mostly OLAP. But should I just include the resource_id attribute just so the data is there?

@ZhangTerrence ZhangTerrence removed their assignment Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants