This page lists the identified improvements that might be present in some future version of the product.
Multi-tuple records. Such a feature would make it possible for a dba to define a single record that can hold (data from) tuples of multiple distinct relvars. One can then define a logical model in 6NF for some application (with e.g. 50 relvars holding each one customer attribute/property), and instruct SIRA_PRISE to store only one record per customer with all 50 attributes combined, including all necessary incidators to manage the absence of (one or more tuples holding a value for) some of the attributes in the record. In yet other words, it is about allowing the storage of tuple records that are "remarkably resemblant" to the "outer join" of the tuples concerned.
Improve data access strategies. Quite a bit of attention has already been given to the subject of optimising data access strategies, but this work is of course never final and complete. Technical improvements such as multi-threaded evaluation of e.g. nested expressions, are still completely absent.
Complete the set of supported relational operators. Operators such as generalized transitive closure and TTM's summarize (as opposed to summarizeby) are not yet operational.
Alleviate all the restrictions on database constraint expressions. In a few very specific circumstances, the usage of certain specific relational operators in a database constraint still isn't supported. These cases are : RESTRICT expressions where the restrict condition involves a reference to any database relvar, EXTEND expressions where any one of the extend expressions involves a reference to any database relvar, and RESTRICT expressions where the restrict condition involves an operator invocation that has an interval value as an argument, and that interval value is itself in any way the result of a relational operator invocation. The first two of these cases won't be solved so easily, but the third one should be addressed, even if the situation seems rather "exotic" and the need for that situation to be supported is likely to be rare.
External transaction monitors. Transactions involving the SIRA_PRISE server are controlled at the client level. The facilities needed to incorporate the operation of SIRA_PRISE into a transaction that is controlled by an external software component are not yet present, however. Allowing this will involve, a.o., supporting two-phase commit in line with some commonly used protocol.
Distributed databases. SIRA_PRISE has no facilities that allow multiple servers to form a "server complex" and act to the outside world as if they were one single server engine. Such a feature will also require two-phase commit to be supported.
Database statistics. Collection of database statistics is still quite rudimentary. Significant extensions and/or improvements may be possible.
Extend database management functionality. Quite a number of database management operations are still unsupported (e.g. moving an index to a different physical location). Allthough in practice, bypasses are normally available to circumvent the problem (e.g. define an additional index in the desired location, and then drop the old one), this means that the job of database administration may have an "uncomfortable feel" over it, and users might like support for database management (or "database administration" if you prefer that term) to be lifted to a more acceptable level.
Various refinements in the catalog. A concept of "attribute aliases" is missing, which somewhat aggravates the workload in defining all required attributes. E.g. often relvars must be defined which establish a "parent-child" or "bill-of-material" relationship between two occurences/appearances of something. Such relvars typically contain two attributes of the same nature, and from the perspective of "business analysis", it is often desirable to think of these two attributes as being "the same business element" (e.g. the identification number of a customer). Nevertheless, SIRA_PRISE does not allow the creation of such relvars unless two distinct attributes have been defined in the catalog. Including a concept of "business element" and "element alias" (or "attribute alias") might alleviate this.
Quota queries. No support is currently present to allow the user to specify queries of the general nature "give me the first ... tuples of ... ordered by ...".
Fully support the CACHE command, allowing repeated use of queries and assignment statements that have been compiled only once.
Complete support for the concept of constrained types : inherit the operators, automatically define the corresponding interval type if applicable, etc. etc.
SIRA_PRISE currently offers only a "shorthand" way for defining the database constraints that correspond to relvar keys. There is no similar way to define the database constraints that correspond to what is commonly known as "referential integrity". Those constraints must all be specified explicitly under the form of some (SEMI)MINUS invocation. Providing a way analogous to how keys are specified might be desirable.