...
The initial decision regarding DB schema is described in in CCSDK-2756 DM: [Spike] Propose C&PS Data Model document.Model#2.2Genericschema(currentproposal)
It was decided to store anchor and data fragments in a same table (FRAGMENT).
...
Anchor and data fragments are different data types, which are managed differently. Even the sets of fields are not intersected.
So there there is no any benefit storing anchors and data fragments at the same table. In opposite there is an extra complexity
managing both anchors and data fragments + performance impact.
Proposal
While there is nothing justifies initial decision it makes sense seems reasonable to split anchor and data fragment storage to two separate tables.
...
- Logical data separation, no confusion, no necessity for explicit description why configuration and data are stored at same table
- Performance improvement, due to number of anchor records (expected) is significantly lower then the amount of data fragments
- No extra complexity in data processing (CRUD implementation) and dependency management (FK constraints)
Cons: none
- Some refactoring work
Mitigation: make decision soon and act on up to prevent it becoming more difficult
| Drawio | |||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Discussion results
The proposal was accepted as reasonable (Jan 11, 2021).
The modification was done via
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
The latest DB Schema (as implemented) is documented on CPS Internal Relation DB Schema