A temporal database is a database with built-in time aspects, for example a temporal data model and a temporal version of Structured Query Language.
More specifically the temporal aspects usually include valid-time and transaction-time. These attributes go together to form bitemporal data.
Valid time denotes the time period during which a fact is true with respect to the real world.
Transaction time is the time period during which a fact is stored in the database.
Bi-temporal data combines both Valid and Transaction Time.
Firstly i am removing that part which i have added previously as MySQL5.1 and its above versions of MySQL does not support
BDB.have a look at This Link.But in My Opinion what the
BDB was doing the
InnoDB is capable of Doing all. *As BDB is not supported anymore By MySQL.But the InnoDB is able to do all which the BDB was doing.*
For More Information About temporal database have a look at This.
With MySQL, The unavailability of
CHECK CONSTRAINT,DEFERRED CONSTRAINT, and some limits on triggers, make it harder to build
temporal relational database architecture in MySQL.
A CHECK CONSTRAINT is often of the form CHECK( [NOT] EXISTS( select_expression ))
MySQL implements foreign key constraints in INNODB tables, but does not yet implement CHECK CONSTRAINT. Until it does, such constraints must be enforced by other means. That has onerous consequences for time-valid tables. Some time-valid constraints can be enforced in triggers, but most of the temporal constraints we will consider cannot. Until MySQL implements CHECK CONSTRAINT, they must be enforced in application code. That is a heavy penalty.
MySQL does not yet implement deferred constraints, either. Furthermore, constraints are applied row-wise rather than at COMMIT time. This raises a problem for many complex constraints, even for some simple ones. For example to delete a MySQL row which refers to itself via a foreign key, you must temporarily SET foreign_key_checks = 0. A transaction fulfilling a complex constraint must leave the database in a consistent state.But there is nothing in relational database theory to suggest that a database should be in a consistent state after each statement within a transaction.
MySQL 5 triggers cannot issue UPDATE statements on the trigger table, and cannot raise errors. These limitations create difficulties for implementing transaction validity in MySQL, but the difficulties can be overcome.