A compliant repository can also be implemented on top of a database. Consider again the following repository structure:
Node/
Property = "..."
/
├─newpaintings
│ └─bigredstripe
│ ├─jcr:created = "2001-05-03T00:00:00.000Z"
│ │
│ └─jcr:content
│ ├─myapp:image = <binary data>
│ └─myapp:desc = "An excellent example
│of stripeism."
│
└─oldpaintings
└─sistinechapel
├─jcr:created = "2001-06-04T00:00:00.000Z"
│
└─jcr:content
├─myapp:image = <binary data>
└─myapp:desc = "Not bad."
One possible implementation is to use four tables, aNODES table and threeXXXX_PROPERTIES tables, one for each of the three property types used in the example:
NODES
name | id | parent_id |
<jcr:root> | 0 | 0 |
newpaintings | 1 | 0 |
bigredstripe | 2 | 1 |
jcr:content | 3 | 2 |
oldpaintings | 4 | 0 |
sistinechapel | 5 | 4 |
jcr:content | 6 | 5 |
DATE_PROPERTIES
name | value | parent_id |
jcr:created | 2001-05-03T00:00:00.000Z | 2 |
jcr:created | 2001-06-04T00:00:00.000Z | 5 |
TEXT_PROPERTIES
name | value | parent_id |
myapp:desc | An excellent... | 3 |
myapp:desc | Not bad. | 6 |
BLOB_PROPERTIES
name | value | parent_id |
myapp:image | <BLOB> | 3 |
myapp:image | <BLOB> | 6 |