RDBMS trade-offs - 2
Conceptual and structural mismatch between design and implementation(1)
SQL92 language not well-suited to spatial domain(2)
SQL not computationally complete; requires additional language (2)
RDBMS does not support long transactions (3)
Notes:
(1) A case can be made where attaching behaviour to all objects actually limits their use in situations with multiple different sets of requirements for the data. This does not lessen the need for more intuitive and reusable design frameworks such as hierarchy and inheritance. Emerging versions of SQL3 are addressing this issue.
(2) The 1998 SQL-3/Multi-Media (spatial extensions) standard will address some of these issues. For example, it will include object identifiers, three spatial object types, rudimentary spatial domain query operators, and support for hierarchical data structures. It also introduces a computationally complete language in which triggers may be written - which may never happen in real implementations as vendors are likely to use Java(Script) instead.
(3) Some GIS vendors are planning to support long-transactions in their GIS software which provides a thick layer between the user and the underlying RDBMS.