What the Yahoo posters think of EXLN, Part 4:
Re: OODB vs RDB
by: mws@metis. 1/10/00 8:41 am
Msg: 4162 of 5672
>could you please explain the advantages that
>OO databases >have over relational databases as more information is stored in XML/Java world.
>Does OO have the potential to also become a
>very hot market, in that it exeperiences the
>expected growth that people once thought it
>could? If so, then ODIS has three legs:
>Objectstore, eXcelon and Javlin. Why couldn't
>this be as big as Oracle some day? Your
>thoughts or anyones elses. Thanks.
We can visualize the natural structure of data. Remember that data is the plural of datum, so data refers to a collection of atomic items of information. The collection can be very large, many hundreds ofmillions of items. When we are talking about computers and the internet, the atomic items of information are always numbers. We can go lower than that, down to the level of bytes and bits, but bytes and bits are usually only useful for talking about data transfer rates,not the data themselves. For talking about the difference between OODB technology and RDB technology, we want to talk about data at the level of numbers. At that level, each number has some meaning that depends on the context of where the number is used. We can take two such contexts, a family history and a census catalog.
We can visualize a family history as an upside down tree. We usually call it a family tree. The original mother and father are at the top (root) of the tree. Directly below them, their children form the first level of the tree. People from outside the family marry these children, and these new families have children, which make up the next lower level of the tree, and so on. As we go down the family tree, each new level gets wider, ie there are more families at each new level than there are at the level above, so the tree gets wider as we go deeper (forward in time).
We can visualize a census catalog as a huge book of rows of numbers. Each row represents a person, and the rows may be sorted in some order, by name, say, or social security number. But other than that order, there need be no relationship between the person at row 17 and the person directly below at row 18 on the same page of the catalog. All the rows are the same length. Each contains the person's name, date of birth, address, height, weight, etc, whatever is needed for the census.
General rule #1: An OODB can store the family tree better than an RDB, and an RDB can store the census catalog better than an ODB.
Here, "better than" refers mainly to amount of space required to store the data and the amount of time required to access the data (use it). We want to minimize both the amount of space occupied by the data and the amount of time required to access it. The rule is a general rule; it isn't always true, and I'll come back to it later.
General rule #2: Most of the data accessible on the web right now is stored in HTML, which, by means it is structured like the family tree example.
Whenever you click on a link in Netscape or Explorer, you are, effectively moving from one page (family) in the tree to a page(child) at the next lower level of the tree. The structure of the HTML pages might actually be a network instead of a tree, but we can think of a tree as being a special case of a network, ie a tree is a network with no loops in it.
General rule #3: XML is a replacement for HTML.
XML is much more than a replacement for HTML. There is a lot more to it than that. Nevertheless, to understand why there is such a rapid movement to XML at the moment, it is useful to think of it as a replacement for HTML.
Re: OODB vs RDB (part II)
by: mws@metis.no 1/10/00 8:42 am
Msg: 4163 of 5672
In light of the above discussion, the conclusion has been that OODBs are finally finding their rightful place in the world as the best way to store data for use on the internet. But this does *not* mean that RDBs are dead, as someone said yesterday. We still have the need for storing large catalogs like the census catalog described above, and,
generally speaking, the RDB approach is still the more efficient way to do this.
However, if we need both a family tree structure *and* a census catalog structure in our application, which is quite often the case, *then* the OODB approach is better than the RDB approach, because it is much easier and more efficient to store a person's census data at his position in the family tree than it is to store all his family relationships in his row in the catalog. This is because catalog rows have a fixed number of fields and tree levels do not. As we go deeper and deeper into the family tree, each level of the family tree is wider than the level above it (normally), but all the catalog rows are the same size.
The truth is that both the OODB and the RDB can be used to store either structure. It's just that if you try to store a tree structure in the RDB tabular form, you waste a lot of space, which violates the goal of minimizing the space required to store the data. However, by storing each person's census data at his position in the family tree, we make the family tree much bigger. This causes an increase in
something called page faults, when the tree is traversed to access the data. Page faults increase when the data gets more spread out. You can see why that would happen when we store a person's census data at his node in the family tree. Suddenly his node becomes bigger, so the nodes of his siblings are further away. This translates into forcing the computer to load more "pages" of memory from the disk. When the data I want isn't on the any of the pages I have loaded, it is called a page fault.
A second reason why RDB technology is not dead is that it is quite simple to translate a row of data in an RDB table into XML and serve it to a client on the internet. In that case, the client doesn't care whether the data came from an OODB or an RDB. the client gets the same XML either way. The only differentiators are the relative efficiencies of storage and of access, and if the differences are not
significant, then it doesn't matter which technology you use.
After all that, I hope you can get the flavor of why OODB technology is better suited than RDB technology for storing and accessing data over the internet. But having illustrated that point (hopefully), I'll say that the OODB/RDB war doesn't really matter any more. It doesn't matter who won, or, if the war isn't over yet, it doesn't matter who is winning. There reason is there are bigger fish to fry, and this is one place where I think ODIS is winning. One big reason that ODIS will stand out is because of its data caching system which refers to its ability to allow multiple users to have access to the same data by having that data cached (stored temporarily) at or near
where the client needs to use the data, instead of forcing all those clients to compete for access to that data. Having made this claim, I will leave it for someone else to explain how it works, not least because I don't understand it yet myself. |
