As you can read in the overview article a BEdita Object consists of one or more tables. All BEdita objects have the objects table as a common element, and they can have specific fields defined in other tables linked by a one-to-one relationship with objects table.

Every BEdita object has one row and the same id in every table involved. For example the image object type is defined by four tables: objects, contents, streams and images. When a new image is added to BEdita a new row with the same id will be inserted in each tables.

However a BEdita object can have other properties than those defined through the base object tables. It can have tags, categories, and others with their own table and are linked to the BEdita object.

Integrity constraints are used between BEdita object tables and properties involved for ensure consistency of data and to perform cascading delete. In this way deleting a row on the objects table will remove all references to that object in the database. This is powerful but requires attention when creating schemas for new tables.

For example  you can see below a portion of the contents schema table (MySQL version here):

CREATE TABLE `contents` (
`id` INTEGER UNSIGNED NOT NULL,  
`start_date` DATETIME NULL ,  
...  
PRIMARY KEY(id),  
FOREIGN KEY(id) REFERENCES objects(id) ON DELETE CASCADE ON UPDATE NO ACTION) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT = 'general contents data' ;

in particular:

FOREIGN KEY(id) REFERENCES objects(id) ON DELETE CASCADE ON UPDATE NO ACTION

defines the integrity constraints between contents.id and objects.id:

• no row on contents can be inserted without a relative row in objects
• when a row in objects is deleted then the relative row on contents will be removed

To see more examples have a look at bedita/bedita-app/config/sql/bedita_mysql_schema.sql