---
# System prepended metadata

title: ACB represented by the relational DB schema

---

# ACB represented by the relational DB schema

![](https://i.imgur.com/XDbiSWW.jpg)

Seems like the above schema is effectively same what Michał suggested in [here](https://hackmd.io/puMEbJH-RqOPkXlsJPwLCQ#Mappings).

| Michał's version  | Patryk's version  |
|-------------------|-------------------|
| Path              | inodes            |
| Paths             | dirents           |
| ContainerPaths    | containers_map    |
| Container         | container         |
| ContainerStorages | storages_map      |
| Storage           | storages          |

## Misc

- Notice that if storage is a separate entity that can be assigned to multiple containers, we can use one syncer to sync all of the containers at once.
- How the module using ACB can be sure that ACB is not cheating in any way?
- How are we going to sign relationships between dirs? Which relationships need to be resigned if we rename some directory in a directory tree? Potentially we can make use of [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree)?
- What is `template_id` for?
- Were are we going to keep storage templates? In ACB?
- In most Unix filesystems, a directory is a mapping from filenames to inode numbers, and there's a separate table mapping inode numbers to inode data. (The inode data contains file metadata such as permissions and timestamps, the location of file contents, etc.) The mapping can be a list, a hash table, a tree...