Right from the start, Polyhedra was developed "to bring the benefits of relational technology to the embedded market". To this end, it had to be small footprint, very fast, high-integrity, ... and it had to avoid the need for polling, which is a performance killer. Consequently, it was designed from the start to:
- keep the working copy of the data in-memory (though there is now a variant that keeps the data in a flash-based file, and another that uses a different database system as the data store);
- use a client–server architecture to protect the data from corruption by rogue application code;
- have an active query mechanism to update client applications when relevant database changes occur;
- have a very simple processing model where a transaction is either a schema change, a query, or a request for a set of inserts, updates and/or deletes - such alterations can either be expressed via SQL statements or by updating through the active queries with (in conjunction with active queries) an optimistic concurrency mechanism to handle clashing updates;
- have a table inheritance mechanism which, when combined with database triggers (via the CL language), allows the database designer to program the database in an object-oriented fashion. Table inheritance also avoids or reduces the need for supplementary tables whose primary key is a foreign key to another table, and thus can simplify many queries and updates.
Polyhedra IMDB achieves data persistence through the use of snapshots and journal logging; Polyhedra Flash DBMS uses shadow paging, with 2 levels of recursion. In addition, both Polyhedra IMDB and Polyhedra Flash DBMS can be used in hot-standby configurations
for improved availability. The transactional model used by all Polyhedra products ensures atomicity, consistency and isolation (as defined by the ACID properties); durability is enforced in Polyhedra Flash DBMS, while in Polyhedra IMDB clients can choose the durability model when they issue their transactions.
Benefits of relational database:
|"The Polyhedra DBMS system is fundamentally different compared to other relational systems, because of its active behaviour. This is achieved through two mechanisms, active queries and by the control language (CL). An active query looks quite like a normal query where some data is retrieved and/or written, but instead the query stays in the database until explicitly aborted. When a change in the data occurs that would alter the result of the query, the application is notified. The CL, which is a fully object-oriented script language that supports encapsulation, information hiding and inheritance, can determine the behaviour of data in the database. This means that methods, private or public, can be associated with data performing operations on them without involving the application."
(Aleksandra Tešanović, Dag Nyström, Jörgen Hansson, Christer Norström: Embedded databases for embedded real-time systems: a component-based approach, 2002)
Deployed in high performance and mission critical applications world-wide,
Polyhedra IMDB provides data management solutions for embedded systems, and for
higher level servers being accessed by applications running on embedded
applications. In either scenario, Polyhedra's fault tolerant, high performance
off-the-shelf solutions assure success, allowing companies to accelerate their
time to market while reducing development costs.
Simple data organization into tables with rows and columns
Ease of data manipulation and access using industry-standard SQL
Seamless handling of multiple, simultaneous read/write connections
Thorough transaction management of "Writes" ensures that "readers" have a consistent view of the data and assurance of data integrity.
Shortened learning curve through the use of industry-standard interfaces (ODBC
and JDBC, SQL, OLE-DB etc.)
Polyhedra IMDB is not a general-purpose DBMS, as its simple transactional model does not meet all needs, and its fault-tolerance model is based on the hot-standby approach (to minimise hardware costs) rather than clustering (which is better for load-sharing). However, its limitations are benefits in embedded use, where the emphasis in a deployed application is on performance and cost rather than handling continually varying usage patterns.