Advantages Of An ODBMS
Advantages Of An ODBMS
We can list some of the advantages that we have found in using an ODBMS environment for a website.
Simplicity
We have no doubt that the simplicity of using an ODBMS contributes significantly to our ability to rapidly develop and deploy new functionality and bug fixes. It is extremely straightforward to create and persist Abstract Data Types, since the persistence mechanism directly supports classes and objects, requiring no extra work to map classes to tables (as required by an RDBMS implementation). An ODBMS also directly supports inheritance, which means that no difficult design decisions have to be made regarding the splitting of instance variable storage across tables.
Development cycles are measured in weeks and days - not the months that have typically been the case in many projects that we have worked on. In our opinion much of our efficiency can be attributed to our use of a Java ODBMS. The transactional model of the ODBMS is easy to understand, there is no database language syntax to learn, over and above that of the implementation language. Developers do not need to
use another language to express the database schema, because the Object Model as defined by the Java application classes is the schema.
Schema Management
The persistent Object Model is identical to that of the application class hierarchy. Managing a persistent Object Model is far simpler than managing an environment where the in memory structures are different than those on disk. However, care must be taken in designing the entry points to the large collections of root objects in the system. Less experienced developers often err in creating multiple root objects for the same underlying tree of objects, leading to confusion and incoherency in the model.
Code Independence
We have found that the completely non-invasive transactional model makes it possible to insulate most business objects in the system from having any knowledge of the underlying database. This is important in the event that we might have to migrate to some other environment at a later stage.
Knowledge of the persistence mechanism system is encapsulated in 27 of the 1000 (or so) application classes. While some O/R mapping environments will allow for a clean separation of this knowledge, many OO systems making use of an RDBMS must directly embed knowledge of SQL and tables deeply in the application classes themselves.
It is important to clarify the above point, no-where in our system does any object have to actively participate in the mechanism used to persist it. This is often the case in either purchased or home-grown O/R mapping frameworks, since classes need to have some knowledge
of what tables they fit in. It is only due to the fact that objects are persisted as objects and not fragmented into various atomic database types that this is possible. The knowledge of the persistence mechanism that is embedded in the 27 or so “aware” classes is purely related to obtaining connections to the database and management of database specific transactional mechanisms.
Natural Object Model
In an environment that uses an ODBMS, objects that refer to other objects always “contain” the object that they reference. What we mean by this is that there is no distinction between an “in-memory” object and an “on disk” object. In systems that make use of an RDBMS, objects are often found to contain a key or an index to the referenced object. Once again, some O/R mapping environments remove this complexity but more often than not, the fact that the referenced object is not actually stored as an object leaks through into the Object Model. Objects are always objects in the ODBMS model, and are always available. This naturalness of expression for the developer as well as the designer is very difficult to achieve in any RDBMS environment.
Collections
Many ODBMS vendors provide highly optimized Collection classes that can be used to provide efficient management of vast numbers of objects. Iteration over (and management of) the collections is straightforward and can be used without any complicated setup routines. We believe this is a distinct advantage to developers.
Performance
Performance is vital to the online experience, online users expect snappy responses. Some architects believe that doing things in a pure OO manner leads to poor performance. In many situations involving the storage and retrieval of objects, an ODBMS does deliver significant performance gains over other persistence mechanisms. We hasten to add that there are some instances when an RDBMS will outperform an ODBMS. These instances often occur when it is
necessary to perform arbitrary queries over large collections of objects.
Design Recovery (quickly and easily correct design mistakes)
By this odd term we mean the ability to quickly and easily correct design mistakes in the class hierarchy/ schema. Since the schema of the database is the class hierarchy as defined by the Java classes in the system, changing a class definition to correct a mistake in design or implementation is relatively simple.
In systems where there is a distinction between the class hierarchy and the database schema correcting flaws can become a complicated matter. Because the schema of an RDBMS is available to other modules (possibly developed outside of the scope of the larger system) errors are often introduced when making changes to the database structure. Changes to the RDBMSs schema may differ from the expectations of external programs. Such conflicts cannot occur in a true ODBMS since there is no difference in structure between in-memory in-use instances and those persistently stored on disk. There are however other problems that can occur when changing schemas.
Retention of Objects
Developers make mistakes. In an RDBMS these mistakes may occasionally lead to situations where inadvertently deleting a row in a table can lead to dangling references, since triggers are often imperfectly implemented. An ODBMS with Garbage Collection based object removal completely eliminates this problem. Persistent objects are only “deleted” once they are no longer referenced by any other instances reachable from a well-defined root object. The ability to recover from an accidental deletion has often allowed system to recover gracefully from potentially embarrassing situations. This has occurred when flawed code eliminates the primary reference to an object. Because other objects still referenced the “deleted” object, it was possible to restore the reference and thus recover the object. Obviously this only works if a persistent Garbage Collection has not been performed.
We can list some of the advantages that we have found in using an ODBMS environment for a website.
Simplicity
We have no doubt that the simplicity of using an ODBMS contributes significantly to our ability to rapidly develop and deploy new functionality and bug fixes. It is extremely straightforward to create and persist Abstract Data Types, since the persistence mechanism directly supports classes and objects, requiring no extra work to map classes to tables (as required by an RDBMS implementation). An ODBMS also directly supports inheritance, which means that no difficult design decisions have to be made regarding the splitting of instance variable storage across tables.
Development cycles are measured in weeks and days - not the months that have typically been the case in many projects that we have worked on. In our opinion much of our efficiency can be attributed to our use of a Java ODBMS. The transactional model of the ODBMS is easy to understand, there is no database language syntax to learn, over and above that of the implementation language. Developers do not need to
use another language to express the database schema, because the Object Model as defined by the Java application classes is the schema.
Schema Management
The persistent Object Model is identical to that of the application class hierarchy. Managing a persistent Object Model is far simpler than managing an environment where the in memory structures are different than those on disk. However, care must be taken in designing the entry points to the large collections of root objects in the system. Less experienced developers often err in creating multiple root objects for the same underlying tree of objects, leading to confusion and incoherency in the model.
Code Independence
We have found that the completely non-invasive transactional model makes it possible to insulate most business objects in the system from having any knowledge of the underlying database. This is important in the event that we might have to migrate to some other environment at a later stage.
Knowledge of the persistence mechanism system is encapsulated in 27 of the 1000 (or so) application classes. While some O/R mapping environments will allow for a clean separation of this knowledge, many OO systems making use of an RDBMS must directly embed knowledge of SQL and tables deeply in the application classes themselves.
It is important to clarify the above point, no-where in our system does any object have to actively participate in the mechanism used to persist it. This is often the case in either purchased or home-grown O/R mapping frameworks, since classes need to have some knowledge
of what tables they fit in. It is only due to the fact that objects are persisted as objects and not fragmented into various atomic database types that this is possible. The knowledge of the persistence mechanism that is embedded in the 27 or so “aware” classes is purely related to obtaining connections to the database and management of database specific transactional mechanisms.
Natural Object Model
In an environment that uses an ODBMS, objects that refer to other objects always “contain” the object that they reference. What we mean by this is that there is no distinction between an “in-memory” object and an “on disk” object. In systems that make use of an RDBMS, objects are often found to contain a key or an index to the referenced object. Once again, some O/R mapping environments remove this complexity but more often than not, the fact that the referenced object is not actually stored as an object leaks through into the Object Model. Objects are always objects in the ODBMS model, and are always available. This naturalness of expression for the developer as well as the designer is very difficult to achieve in any RDBMS environment.
Collections
Many ODBMS vendors provide highly optimized Collection classes that can be used to provide efficient management of vast numbers of objects. Iteration over (and management of) the collections is straightforward and can be used without any complicated setup routines. We believe this is a distinct advantage to developers.
Performance
Performance is vital to the online experience, online users expect snappy responses. Some architects believe that doing things in a pure OO manner leads to poor performance. In many situations involving the storage and retrieval of objects, an ODBMS does deliver significant performance gains over other persistence mechanisms. We hasten to add that there are some instances when an RDBMS will outperform an ODBMS. These instances often occur when it is
necessary to perform arbitrary queries over large collections of objects.
Design Recovery (quickly and easily correct design mistakes)
By this odd term we mean the ability to quickly and easily correct design mistakes in the class hierarchy/ schema. Since the schema of the database is the class hierarchy as defined by the Java classes in the system, changing a class definition to correct a mistake in design or implementation is relatively simple.
In systems where there is a distinction between the class hierarchy and the database schema correcting flaws can become a complicated matter. Because the schema of an RDBMS is available to other modules (possibly developed outside of the scope of the larger system) errors are often introduced when making changes to the database structure. Changes to the RDBMSs schema may differ from the expectations of external programs. Such conflicts cannot occur in a true ODBMS since there is no difference in structure between in-memory in-use instances and those persistently stored on disk. There are however other problems that can occur when changing schemas.
Retention of Objects
Developers make mistakes. In an RDBMS these mistakes may occasionally lead to situations where inadvertently deleting a row in a table can lead to dangling references, since triggers are often imperfectly implemented. An ODBMS with Garbage Collection based object removal completely eliminates this problem. Persistent objects are only “deleted” once they are no longer referenced by any other instances reachable from a well-defined root object. The ability to recover from an accidental deletion has often allowed system to recover gracefully from potentially embarrassing situations. This has occurred when flawed code eliminates the primary reference to an object. Because other objects still referenced the “deleted” object, it was possible to restore the reference and thus recover the object. Obviously this only works if a persistent Garbage Collection has not been performed.
Categories:
Code Independence,
features,
Natural Object Model,
ODBMS,
Schema Management
0 comments:
Post a Comment