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, a NODES table and three XXXX_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 |