# eXtremeDB Database Features

> As mentioned in the Schema Definition page, eXtremeDB provides a number of specific data storage capabilities. These features are described briefly below. For more a detailed description please use the associated links:

> - `transient` or `persistent` classes: The database designer specifies whether objects of specified classes are stored in memory only (conventional or shared memory) or on persistent media. It is also possible to create hybrid databases which contain both `transient` and `persistent` objects.
> - `dynamic fields`: Fields of type `string`, `blob`, `vector` and `varbinary` are initialized as 2 or 4 byte addresses in the data layout when objects of their class are created. They do not occupy storage until explicitly written to the database.
> - `automatic de-fragmentation`: The automatic de-fragmentation algorithm reallocates objects, eliminating any internal fragmentation.
> - `optional` structures: An `optional` declaration means that the field may or may not be actually stored in the database. If the field is not stored, the runtime does not reserve (allocate) space for it within the data layout except a 2 or 4 byte reference address.
> - `direct` structures: The `direct` specification is an efficient optimization that can be applied to fixed sized class layouts in C or C++ applications. Direct structures organize data fields as structure elements and internally store data as a C-language `struct`.
> - `nullable` fields: Any field can be declared nullable, except sequence fields. The nullable attribute adds one byte of overhead (for a null indicator field).
> - `voluntary` indexes: The `voluntary` qualifier for an index means that the index can be initiated or dropped at runtime. Voluntary indexes are not built until an explicit call is made by the application. In the same fashion, the application can remove a voluntary index at runtime.
> - `unique object identifiers`: The `oid` definition is available in C and C++ applications to specify that a class is stored with an `oid` of an application specific type defined in the `declare oid` statement. Alternatively an `autoid` may be declared in all the native language APIs to specify that a class is stored with a system-generated unique identifier.The eXtremeDB runtime maintains a special index for `autoids` stored in the database to facilitate efficient lookups.
> - `database events`: Event statements declare that the application will be notified of specific database events, such as: adding a new object, deleting an object, updating an object or a specified field of an object (with the exception of array and vector fields), and checkpoint events.
> - wide character support: Wide-character fields store Unicode characters that are sorted according to the machine’s `locale` setting.
> - `alternative collations`: Support for custom collations in C and C++ applications.
> - `binary schema evolution`: “Binary schema evolution” (BSE) allows an application to alter the database schema of a stored database image to a new definition.
> - `binary` fields: Binary data can be stored in fields of type `blob`, `string,``binary` and `varbinary`.
> - `datetime fields`: The eXtremeDB`datetime` type is a 64 bit integer value used to store the date and time in databases.
> - `vertical data storage`: The `sequence` declaration can be used to specify a field that contains a variable length array of values. The Analytics functions library provides a multitude of statistical functions that operate on ``sequence`` fields.