Object Database VS relational database

Object | data | Database object Database VS relational database
We define the object database management system (ODBMS) as a database management system (DBMS) that integrates database capabilities with object-oriented programming language capabilities, and Odbms makes database objects look like programming languages in one or more programming languages that are already in place. Chairman of the--rick cattell,omg-93 Committee.

Odbms provides persistent storage in a multiuser client/server environment. Odbms can handle parallel access to objects, provide locking and transaction protection, protect object storage from various types of threats, and care for traditional tasks such as backup and recovery. Odbms this is so different from the relational database because Odbms stores objects, not tables. The reference to the object is made by persistent identity (PID), which uniquely identifies each object and can be used to establish a tag and container relationship between objects. Odbms also strengthens the encapsulation to support inheritance. Odbms combines object attributes and traditional DBMS functions such as locking, protection, transaction processing, querying, layout-oriented, concurrency, and persistence.

Instead of defining, retrieving, and processing data using discrete languages such as SQL, Odbms uses class definitions and traditional object-oriented programming languages (usually C + +, Smalltalk, and Java languages) constructs to define and access data. Odbms is a multi-user, persistent extension of the data structure in memory. In other words, the customer is a C + + or Java program, and the server is odbms--without visual intermediate objects like SQL and RPC. ODBMS integrates database capabilities directly into the language.

The value of Odbms. Obviously, it's best to store those objects in a natural form rather than pieces the data into a relational table after it has been polished or torn.

Odbms is especially suitable for users whose data is complex and difficult to arrange in a simple form. Odbms has long been an area of great interest for academics and OO researchers. The first commercialized Odbms appeared in 1986, and was launched by Servio (now gemstone Company) and Ontos Corporation. Later (90), the Object Design (ODI), versant, objectivity, O2 Technology, poet, Ibex, Unisql and ADB Matisse and other companies joined the pioneering ranks. The Odbms vendors first targeted applications for complex data structures and long-lived transactions-including computer-aided design, case and intelligence offices. With the advent of multimedia, groupware, advertisement objects and World Wide Web technologies, Odbms and those esoteric features now become the mainstream requirements of client/server systems. Odbms technology fills the weakest gaps in relational databases-complex data, layout-oriented and long life transactions, persistent object storage, inheritance and user-defined data types, and so on.

The following are the characteristics of the Odbms vendors to explore:

n Create new types of information freely

N Fast Access

n flexible view of combined structure

n is tightly integrated with object-oriented programming languages

n supports customizable information structures with multiple inheritance

N supports version transactions, nested transactions, and long Life transactions

N Distributed Object Storage

N Support for life-cycle management of composite objects

The object maniac has mastered the whole industry. Object-oriented technology advocates are declaring that object relational databases and Odbms will be a good antidote to the so-called weaknesses in the healing of relational technologies. This is pure nonsense ... The application of object-oriented technology directly and without distinction on the database will bring together the problems that the relational database has taken 20 years to overcome.

Among users, few doubt that Odbms will eventually become a successor to the RDBMS. In the Parable of William Blake The poet, the young revolutionary God Orc has begun to grow old and become a cold tyrant urizen--commandment and Standard Guardian.

We can have both. The point is to combine the two techniques, rather than throwing the pieces of dirt at each other. The development of more than 20 research on relational database has turned a blind eye, not to use, it is not enough.

Both date and Pascal acknowledge that the current SQL database implementation is flawed; but both of them feel that the relational model itself can handle the problems Odbms will address, Odbms has the ability to exploit nested relationships, Domains (or user-defined data encapsulation types) and a more powerful set-oriented language than SQL are similar in the relational technology world. These features do this without chasing object pointers or manipulating low-level private language recording structures. There is no need to mitigate the joint capacity of relational theory. There is no need for developers to return to the manual method of optimizing or optimising the application's performance-the clock is being pulled back. Date considers domains and objects to be the same, and the solution is to extend their systems to include "appropriate domain support" by the relational technology vendor.

Stonebraker notes that pure Odbms also lacks functionality in areas such as complex search, query optimizer, and server scalability. Also, many Odbms run their products in the same address space that users program. This means there is no shielding between the client application and the Odbms. In addition, compared with the relational DBMS, Odbms's market breakthroughs are minimal. Finally, object/relationship and SQL data type Extenders meet certain object requirements within the RDBMS language political negotiation environment.

People who support Odbms feel that there are more ways to do this than just extend the relational model. In fact, they have rejected the SQL3 for lack of agreement (a truce is being reached). Odbms that they are creating a better plumbing system for a new world in which information systems are built entirely on the basis of objects. In a pipeline composed of Orb, Object Services, object-oriented programming languages, and object Web, relational databases are blocked. What is needed is a pure Odbms. Why stick with blobs, stored procedures, and user-defined types to extend an old base like SQL? They prefer to stick with object technology from beginning to finish, sometimes borrowing something from SQL (such as queries). They are also creating a multi-user, solid foundation, including locking, handling of things, recovery, and various tools.
Of course we're talking about David and Goliath here. The SQL database is currently the king of the mountains, they have a large amount of development funding, from the MIS store to the client/server low-end market has excellent market acceptance. Is it because Odbms can deal with the object better and the king of the mountain will be abolishing? This remains to be seen further. However, as Esther Dyson expresses, "Using tables to store objects is like driving a car home, then breaking it into pieces and putting it in a garage, and assembling the car in the morning." But one wonders: is this the most effective way to park a car?