These interfaces are also provided to abstract certain behaviour:
* [api:SilverStripe\Assets\Storage\AssetContainer]: Abstract interface for a file reference. Implemented by both
File and DBFile. Declare API for reading to and writing an single file.
* [api:SilverStripe\Assets\Storage\AssetStore]: Abstract interface for the backend store for the asset system.
Implemented by FlysystemAssetStore. Declares API for reading and writing assets from and to the store.
## Storage via database columns
Asset storage is provided out of the box via a [Flysystem](http://flysystem.thephpleague.com/) backed store.
However, any class that implements the `AssetStore` interface could be substituted to provide storage backends
via other mechanisms.
Internally, files are stored as [DBFile](api:SilverStripe\Assets\Storage\DBFile) records on the rows of parent objects.
These records are composite fields which contain sufficient information useful to the configured asset backend in order
to store, manage, and publish files. By default this composite field behind this field stores the following details:
| Field name | Description |
| ---------- | -----------
| `Hash` | The sha1 of the file content, useful for versioning (if supported by the backend) |
| `Filename` | The internal identifier for this file, which may contain a directory path (not including assets). Multiple versions of the same file will have the same filename. |
| `Variant` | The variant for this file. If a file has multiple derived versions (such as resized files or reformatted documents) then you can point to one of the variants here. |
Note that the `Hash` and `Filename` always point to the original file, if a `Variant` is specified. It is up to the
storage backend to determine how variants are managed.
Note that the storage backend used will not be automatically synchronised with the database. Only files which
are loaded into the backend through the asset API will be available for use within a site.