Object database VS relational database
We define the object database management system (ODBMS) as a database management system (DBMS) integrating database capabilities and object-oriented programming language capabilities, and ODBMS makes database objects look like one or more programming languages in existing one or more programming languages. Programming language is like icon. - Rick Cattell, Chairman of the OMG-93 Committee.
ODBMS provides a persistent memory in a multi-user client / server environment. ODBMS can handle parallel access, providing lock and transaction protection, protecting object memory from various types of threats, and traditional tasks such as backup and recovery. ODBMS This is thus different from the relational database because ODBMS is stored objects instead of forms. The reference to the object is performed by a persistent marking (PID), and the PID can identify individual objects unique, which can be used to establish tags and container relationships between objects. ODBMS also enhanced packaging and supports inheritance. ODBMS combines object properties and traditional DBMS features such as locking, protection, transaction processing, query, layout, concurrency, and persistence.
ODBMS is not defined by separate languages (such as SQL), retrieves, and processing data, rather to define and access data using class definitions and traditional object-oriented programming (usually C , SmallTalk, and Java Language). ODBMS has only been multi-user, persistence expansion of language data structures in memory. In other words, the customer is C or a Java program, and the server is ODBMS - there is no visual intermediate object like SQL and RPC. ODBMS integrates database capabilities directly into the language.
The value of ODBMS. Obviously, it is best to store those objects in nature, rather than putting data modifying light slide or putting the relationship table after torn seven zero.
For those who are difficult to arrange in the table, ODBMS is particularly suitable for users who are more simple in the form. ODBMS has long been a field of scholars and OO researchers. The earliest commercial ODBMS appeared in 1986, is launched by Servio (now Gemstone) and Ontos. Later (1990s) Object Design (ODI), Versant, Objectivity, O2 Technology, Poet, IBEX, UNISQL, and Adb Matisse also joined this development ranter. These ODBMS vendors first aimed at the application of complex data structures and long-life transactions - including computer-aided design, Case, and intelligence office. With the emergence of multimedia, group parts, publicly objects, and the emergence of World Wide Web technology, ODBMS and those who are difficult to understand now become mainstream requirements of the client / server system. ODBMS technology fills the weakest voids - complex data, layouts, and long life transactions, persistent object storage, inheritance, and user-defined data types, etc.
The following is the features of the ODBMS manufacturer development:
N freely create new information types
N quick access
N-combined structure flexible view
n is closely integrated with object-oriented programming language
n Use more inheritance to support customizable information structure
N Support version transactions, nested transactions, and long life transactions
n distributed object reservoir
n Life management of composite objects
Objects have been madly mastered throughout the industry. Object-oriented technical supporters are being announced that the object relationship database and ODBMS will become a so-called weaknesses of treatment technology. This is purely non-discrepared, and the application of object-oriented technology is directly used in the database, which will again introduce the relational data library for twenty-year overcoming.
In the middle of the user, few people will suspect that ODBMS will eventually become the follow-up technology of RDBMS. In the metaphor of the poet William Blake, the young revolutionary God Orc has begun to aging, turning into a cold ice tyrant Urizen - the commander and standard guardian. We can both. The point is to combine these two techniques instead of throwing mud blocks. The development of more than 20 striking relational database research is clear, and it is not very useful.
Date and Pascal have acknowledged the shortcomings of the current SQL database; but their two have the relationship model itself can handle those problems that will address ODBMS. ODBMS has the ability to utilize nested relationships, domains (or user-defined data packages) Types) and a more powerful set language than SQL is approximate in the world. These features complete this work without chasing the object pointer or manipulating the low-level dedicated language record structure. There is no need to mitigate the combinence of relationship theory. Developers don't have to return to the performance of the application to optimize or reopeize the application with manual methods - pull back the clock back. Date is considered that the domains and objects are the same thing, and the solution is to extend its system by relations technology vendors to include "appropriate domain support."
Stonebraker notes pure ODBMS lacks functions in complex search, query optimizer, and server scalability. Moreover, many ODBMs run their products in the same address space programmed. This means that there is no shield between the client application and the ODBMS. In addition, ODBMS's market breakthrough is extremely small compared to relations DBMS. Finally, the object / relationship and the SQL data type extension meet certain object requirements in the RDBMS language political negotiation environment.
People who support ODBMS feel that in addition to only extension of the relationship model, there are more methods. In fact, they have rejected SQL3, the reason is inadequate (just reaching the battle agreement). ODBMS stubborn molecules believe that they are creating a better pipeline system for a new world, in which the information system is completely based on the object. In a pipeline consisting of ORB, object service, object-oriented programming language and Object Web, the relational database is hindered. What you need is a pure ODBMS. Why do you want to use BLOB, stored procedures, and user-defined types to extend an old foundation like SQL? They would rather insist on using object technology from beginning to end, sometimes from SQL to some things (such as query). They are still creating a multi-user, solid foundation, including locking, things processing, recovery, and tools.
Of course, we talk about it here is
David
with
Goliaath
.
SQL
The database is the king of the current mountain, they have huge development funds, from
MIS
Store to the client
/
There is excellent market acceptance in the low-end market. Is it because
ODBMS
Can deal with the object with better, this mountain will be 黜? This still needs to be further observed. However, just as
Esther Dyson
Expressed, "use the table storage object, just like the car home, then remove the zero strain into the garage, can put the car in the morning. But people can not help but ask: This is the most effective Method? "
