# ACB represented by the relational DB schema


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...