phdru.name / Software / OODB
OODBs are based upon the object model - there are classes, objects, attributes. SQL DBMSes are based upon the relational algebra.
An OODB stores objects. An SQL DBMS stores tables (relations), rows and columns (attributes); data in columns are of simple types - string, integer, float, date/time, currency.
OODB | SQL | ||
---|---|---|---|
advantage | disadvantage | advantage | disadvantage |
Well-known and popular technology. There are SQL standards; there are many implementations and tools of all kinds. | Many different slightly or even not so slightly incompatible implementations; every implementation uses its own subset of the SQL standard, and extends it into its own direction. | ||
There is no impedance mismatch between the OODB and the programming language - the OODB stores language objects. |
The OODB is oriented toward one and only one programming language. Well, in theory it is possible to write serializers/deserializers in different languages, but in practice I don't know of any such interlanguage serializers. |
There is a specified (and often documented) protocol between a frontend and a backend; one can write an implementation of the protocol in any programming language or link with client libraries. Thus a client can be written in any programming language - the server does not care until the FE/BE protocol is fullfiled. |
One always has to go through FE/BE protocol, encode the queries one wants to pass to the server, decode the returned values and convert them to the programming language's data types. |
One has the full power of the relational algebra; there are tables with normalized data and joins of all kinds. |
One has to understand at least the basics of the relational algebra and rules of data normalization. |
||
One can directly manipulate with objects in one's preferred programming language. |
One has to manipulate with objects; for example, if one needs to select a subset one has to iterate over the entire set of objects. (This can be relived if the OODB has higher-level indexing.) |
One can formally describe what subset of rows from what Cartesian product one wants to select. |
One has to formally describe (in a language different from one's primary programming language) what subset of rows from what Cartesian product one wants to select. |
Parallel access and concurrency control; table- and row-level locks; data consistency inside a transaction; serial (autoincremented) counters. |
One is constrained by the set of data types and functions the DBMS provides; however rich the set is often insufficient, and SQL DBMSes seldom allow a user to extend it, and even if they allow - the language to write extensions is usually a different programming language, often proprietary and not portable among DBMSes. |
||
OODBs can store deep hierarchies of objects and complex data types. |
Hierarchical data can be stored in an SQL DB with different tricks, but well, they are just that - tricks and workarounds. SQL DBMSes certainly have problems with complex datatypes. |
This is the page https://phdru.name/Software/OODB/OODB_vs_SQL.html. It was generated on Sun, 16 Jun 2024 10:04:50 GMT from CheetahTemplate OODB_vs_SQL.tmpl. Some rights are reserved. Read more about technical aspects of the site.