DBMS Interview - October 1994
As one of the world's best-known specialists in relational database technology, Chris Date spends much of his time explaining. Software designers and engineers, teachers, nontechnical users, journalists, and others seek him out, looking for answers on this most talked-about yet least-understood, technology. He writes. He lectures. He explains. Fortunately, it's something he enjoys doing. As an independent author, lecturer, teacher, and consultant, Date has devoted himself to this task, while forging ahead with original research intended to augment and refine the relational model itself. He recently worked with David McGoveran to solve problems in view updatability, and collaborated with Hugh Darwen on "The Third Manifesto," a document that defines the qualities and features in relational DBMSs necessary to support object-oriented operations.
Date's books number 22, and his papers number more than 200. His most popular book, An Introduction to Database Systems, has sold nearly 500,000 copies and has just reached its sixth edition. His other books include A Guide to DB2, with Colin White (4th edition, Addison-Wesley, 1992), and A Guide to Sybase and SQL Server (Addison-Wesley, 1992), with David McGoveran. Date continues to write magazine articles, including a monthly column that appears in DBMS's sister publication, Database Programming & Design. He also recently began a collaboration with David McGoveran and Fabian Pascal to produce a newsletter called "The Data Independent."
Chris Date received his B.A. in Mathematics from Cambridge University (U.K.) in 1962, and entered the computer business as a mathematical programmer at Leo Computers Ltd. (London), where he quickly moved into education and training. In 1966, he earned his Master's degree at Cambridge, and, in 1967, he joined IBM Hursley (U.K) as a programming instructor. Between 1969 and 1974, he was a principal instructor in IBM's European education program.
In 1970, he became involved in defining database extensions to PL/1, and, as part of this activity, read Dr. E. F. "Ted" Codd's original Communications of the ACM paper on relational databases. Date and his colleague Paul Hopewell corresponded with Codd, who was then at IBM Research in San Jose, Calif. In 1971, Codd invited Date to the U.S. to give presentations on the PL/1 database effort.
In 1974, IBM assigned Date to IBM California to design database extensions for high-level languages such as Cobol, Fortran, and PL/1, as part of IBM's "Future Systems" (FS) project. While he would have preferred to design just relational extensions, he was instructed to combine the elements of hierarchical, network, and relational technology to match IBM's database product line. In the late 1970s, he accomplished this in UDL (Unified Data Language), and he claims that UDL's relational implementation is still superior to today's SQL. Nonetheless, IBM opted for SQL in its SQL/DS and DB2 products.
With his books gaining him wide visibility, Date found himself in demand as a speaker. He lectured to user groups and IBM customers, and at professional conferences and universities. He enjoyed teaching and believed it demonstrated IBM's leadership in technology. Date's managers at IBM didn't necessarily agree with that assessment. Ultimately, Date left IBM in 1983 and continued to write and teach. He also worked under contract for Relational Technology Inc. (RTI), which later became Ingres Corp. In 1984, Date joined Codd in forming a consultancy, Codd & Date International where he continued to develop and teach classes. Among its activities, the company advised major DBMS vendors on the direction of their relational products. Date left Codd & Date in 1991 to return to the independent status he maintains today.
DBMS's Editor in Chief David Kalman interviewed Chris Date in his home town of Healdsburg, California, which lies in northern Sonoma County, one of the state's major wine-producing regions. The conversation focused on how object-oriented concepts, such as classes and inheritance, fit naturally within the framework of the relational model. An edited transcript of the conversation follows.
DBMS: How did "The Third Manifesto" come about?
DATE: Hugh Darwen and I have watched what the industry has been doing for the last few years, and we've been getting increasingly depressed. Every time we met we'd say we ready ought to do something about this. Finally, this year, Hugh wrote down the first cut of what he caused, "The Third Manifesto," a manifesto for the way we think the database industry should move forward.
The major part of it discusses how to marry object technology and relational technology. We cared it the third manifesto because there have been two previous ones. There was one called, "The Object-Oriented Database System Manifesto," by Malcolm Atkinson and others (Proc. First International Conference on Deductive and Object-Oriented Databases, Kyoto, Japan [1989]. New York, N.Y.: Elsevier Science [1990]). There was a second one called, "Third Generation Database System Manifesto," by Mike Stonebraker and others (ACM SIGMOD Record 19,3 [September 1990]). Ours is thus the third in a series (of a kind). We wanted to do this because we don't think that the first two hack it.
The object-oriented manifesto essentially to ignores the relational model entirely, which we just think is a terrible thing to do. The second manifesto certainly agrees that we must not discard the relational model, but then goes on to say that the relational model means SQL and that we have to live with SQL forever and ever. They assume that everything will grow out of SQL. We think that SQL is such a disaster area, that anything that's going to stand the test of time must be founded on something much more solid. We could talk for hours about the problems of SQL!
A section in The Manifesto, called "Back to the Future," says that to do the foundation right, we must get back to our roots. We must found what we're doing on the relational model. The document then goes on to give a series of prescriptions and proscriptions, and what we can Very Strong Suggestions. There are relational pre- and proscriptions, object-oriented pre- and proscriptions, and relational and object-oriented Very Strong Suggestions.
The document has been through many drafts. We've circulated it to many professional peers and we've received lots of comments, which have been incorporated. Most of the comments have been along the lines that certain details are wrong, but no one has shown that the big picture is wrong. That's encouraging. The more feedback we get like that, the more we have a warm feeling that we're on the right track.
In what ways does the relational model support what we call object-oriented concepts?
Before I try to answer that technically, we have to be clear what we mean by object-oriented. We have object-oriented programming, analysis, design, interfaces, and so on, and we have object-oriented database. There's not necessarily very much in common among these different disciplines. Obviously, I'm talking about object-oriented database and any positives or negatives I say about that may or may not have anything to do with all the other disciplines. We're talking database.
The question is how to integrate the good ideas of object-oriented database with relational ideas. The wonderful thing is, it turns out you don't have to do anything to the relational model. Absolutely nothing. The relational model is so solid and so robust; to quote the manifesto, "The relational model needs no extension, no correction, no subsumption, and, above all, no perversion" in order for it to accommodate the good ideas of OO. Another way to say the same thing is that the good ideas of object-oriented are completely orthogonal to the relational model. We don't have to destroy the relational model to get what we want.
The key question in trying to bring these technologies together is, what in the relational world is the analog of the object class in the object world? The answer is: It is the domain or data type. I use the terms data type and domain interchangeably.
The key notion underlying The Manifesto is thus the equation: domain = object class. A domain, or an object class, is a data type that is encapsulated, which means that the only way you can operate on values of that type is through operators that are defined for the type. You don't actually see the way the data is represented. That's not relevant. You only know that there are certain functions you can perform. It might be a primitive system-defined data type. More generally, it's going to be a user-defined data type. The values of these data types can be arbitrarily complex.
What part of the relational model permits your interpretation of "domain?"
The reason I say the ideas of object-oriented (at least the good ones) are orthogonal to the ideas of the relational model is that nowhere does the relational model prescribe what data types you have. It simply has a mechanism that allows you to define data types.
Object classes and domains really are the same thing. Therefore, a relational system that supported domains properly would be able to do all of the things that the object advocates claim object systems can do and relational systems cannot. You would have relational systems that do CAD/CAM, office automation, medical diagnosis, and all these wonderful things. You'd be able to do it but you would still be in the relational framework. I believe very strongly that we should not get rid of the relational stuff. We shouldn't throw the baby out with the bath water.
This equation, domain = object class seems very simple...
What I want is very simple. I want the vendors to support the relational model properly, including the extension - which is actually not an extension at all - of domains done right meaning they can be data types of arbitrary complexity. The values in row and column slots can then be anything you like. They can be simple integers. They can be strings. They can be arrays. They can be books. They can be engineering drawings. They can be videos... They can be anything you like - as long as you can define the data type. In fact, I believe do one of the reasons we're hearing so much hype about object-oriented is because of a failure on the part of the relational vendors to step up to the mark. They haven't supported the relational model. If they had, we wouldn't be having these silly arguments now.
Also, we have to be very clear about the difference between the type and the representation of the type. If you had a system that supported user-defined domains properly, you could define a domain of employee numbers, for example. The representation might be a character string, but it does not follow that you can perform character-string operations on employee numbers. You can perform the operations on employee numbers that are defined for the domain employee numbers. Those operations might be equals, less than, and so on. Probably not plus and minus. Probably not string concatenation and so on. Even though the representation is a string, you still can't concatenate two employee numbers if the system is implemented right. Most of today's products are very weak in this respect, so you probably could concatenate two employee numbers because they're just strings as far as the system is concerned today. In a system that did this right, you would have this very clear differentiation. The type defines the operations you can perform. The representation is irrelevant, and should be hidden.
If a field holds an array containing several values, doesn't it violate the relational model's guaranteed access rule (where all values must be accessible, by the table name, the column name, and a primary key)?
It doesn't violate First Normal Form. You can have an array in a row and column slot. Let's take a simple data type, such as an integer. This is almost certainly a built-in data type. There are operators called plus, minus, and so on, by which you can operate on these values. There are operators such as less than and equals by which you can do comparisons, and so on. By contrast, there are not string concatenation operators. You can do arithmetic. You can do comparisons. You can't do string concatenations. My point is that integers are encapsulated values. You can only operate on them by means of the operators defined. It's the same with an array.
If I define a data type of arrays of integers, I define the operators that go along with that data type. These operators will probably include subscripting for picking out elements of the array, and so on. With a subscripting operation, I could write a query in SQL that says something like "select* from this table where A[3] = 10." That's no different from saying "select * from this table where some substring of a string is equal to ~abc'." If I can do the string operation, I can do an array operation too. They're exactly analogous. The problem, of course, is that once you recognize that you can have arbitrarily complex values in row and column cells, the database design problem becomes much more difficult. Now you have multiple ways of representing things logically. You have far more freedom, but as far as I know there's not much in the way of good design methodologies. I'm certainly not saying we've solved all the problems. I'm simply saying that if you want object-oriented constructs, this is how to do it.
In an object-oriented database, "employee id" might identify a data structure that contains or refers to facts about an employee. This would be the employee "object." In a relational DBMS, these facts would be treated as a relation. Does this mean that we should consider a relation as an object?
I would say a relation is not an object; rather, a row and column intersection within a relation contains an object. That object can be really simple like an integer, or really complicated like an airplane design, or anything in between. In an object system, you might regard the whole employee "thing" (I wish they hadn't usurped the term object), with the name, salary, job, location, and so on, as a single object. In a relational system, I could define a domain of employees like that, but I probably wouldn't, because I see lots of advantages of having employees not being encapsulated. I'd like to see inside, and see they have a salary, see they have a name, and so on.
What you're really pointing out is that the database design is more difficult in an object system. Now, you have two ways to represent employees. You can have them represented by rows and tables, as we typically do in a relational system. Or you can have a domain of employees. How do you choose? That's not my problem.
If a row and column slot can contain anything, how about a relation?
As soon as people recognize that you can have anything you like in a row and column slot, they rush off and say, let's have arrays, let's have lists, let's have files. I believe that we should investigate putting relations in there. If that turns out to be useful, we can get a lot of mileage with the existing language and the existing knowledge. You don't have to learn very much more.
You can have another relation inside a row and column slot, provided you do it right. Suppose you had a Departments relation with two columns, Department Number and Employees. In any given row, the Department Number column contains a plain old department number, and the Employees column contains another table containing all the employees in that department. So you have a table inside a table. That's okay, as long as you don't look inside the inner table at the same time as you look outside it. That's mixing levels of abstraction.
Some people have been saying for some years that you should be able to have relations inside relations. They call it [NF.sup.2] relations ([NF.sup.2] is non-First Normal Form). The trouble is, they expose the inner structure at the same time that you see the outer structure. They have an extended relational algebra, which is much more complex, and an extended relational calculus, which is much more complex. We're saying, no. If you have a table inside a table, when you perform operations on that inner table, system should simply invoke the appropriate defined functions. Involving these functions is really invoking the DBMS itself in a recursive kind of way. Much of the code is already there. It also means, by the way, do the user doesn't have to learn very much more. Relations are already a familiar structure, and you don't have to extend the language very much.
Then at any specific level of abstraction, a single row and column slot appears as an atomic value, whether it contains a simple or complex value...
Exactly. We say that row and value slots are supposed to hold atomic values. But what is "atomic"? It's in the eye of the beholder, as in physics. An atom in physics has internal structure. But at a certain level of discourse, we don't care about the internal structure.
For certain purposes, a set of employees in a department is a single thing. We know it has internal structure, but for some purposes you ignore it. Same deal. Once you understand this levels business, suddenly it all becomes plain. And you're not violating First Normal Form.
Other so-called object-relational database systems treat relations as objects. What's wrong with that?
There are two possible equations: object class = domain, or object class = relation. I argue very strongly that the domain equation is right, and the relation equation is wrong, but much of the industry seems to be running with the wrong one. There are products out there that make this equation, class = relation. In an interview like this, I can't go into a lot of detail as to why that equation is wrong, but I can make a couple of statements.
Think about domains and relations in the relational world. Domains are sets of symbols that represent things in the real world. Domains effectively give us a vocabulary - the things we can talk about in our database. They define what we're allowed to talk about Relations are what we say about the things we can talk about.
Every relation has what is called a relation predicate. A predicate is a truth-valued function. For example, in the employees relation, you might have employee number, salary, and department. The predicate corresponding to this employees relation is something like "the employee with the specified employee number earns the specified salary and works in the specified department." This is a function of three arguments, the arguments being employee number, salary, and department. If you plug values in, you get a statement that's either true or false. If you plug in "employee 1, $50K, department 1," it may be true. If you plug in "employee 2, $50K, department 2," it may be false. The rows in the relation are precisely the true instantiations of the predicate.
To repeat, therefore: Domains give us the things we can talk about. Relations are the true statements we make about those things. Once you understand this crucial difference, then clearly it cannot be the case that a relation is an object class. It's a very different thing. Philosophically and logically, they have to be different things. Anybody who tries to argue that relation = object class is fundamentally confused. Superficially, people might say, "A row in a table is like an object, and creating a new object is like putting a new row in a table, and destroying an object is like deleting a row, and the columns are like the instance variables of the object." And you can run with this equation for a while. But, later on, the problems will begin to surface.
In a relational database, a complex "object" such as an airplane wing assembly would consist of information stored in various rows in various tables. Didn't the object databases come about, in part, to speed up access to the information stored in highly complex structures?
That is the common perception, but there are two levels of confusion here. The first is not realizing that an object class is a domain. If you really want it you could have a domain of airplane wings where you have one logical table that contains in one of its slots an incredibly complex thing. You could do that in principle, but not in the products because the products haven't implemented the model.
Second, if you didn't want airplane wings to be encapsulated, but wanted them completely open so you could do ad hoc queries, then the domain would probably get split across lots of tables logically. It does not follow that you have to have lots of separate physical files on the disk. That's another place where relational vendors have let us down.
In relational systems, you have base relations and you have views. You have quite a lot of possible variability between views and base relations. Well, you should have at least as much, actually more, possible variability between the base relations and the disk so that even if you have lots of base relations for good design reasons, you still might have one physical file. Unfortunately, the relational vendors give us essentially a very straightforward mapping where one base relation goes down to one operating system file. So, we get into this stuff about denormalization for performance. Of course you may need to denormalize for performance, but it should be at the physical level on the disk. If you change it down on the disk in today's products, you've changed it at the base relation level as well, because there's a one-to-one mapping.
The implied performance criticism of relational is valid if it is directed at the products today. Ifs not valid if it's directed at the potential of the technology. The vendors haven't given us the potential. That's my complaint
What are the other good ideas of object-oriented databases?
In my opinion, there are precisely two good ideas. One is the data type concept - user-defined data use of arbitrary complexity, with encapsulation and user-defined functions. The other is inheritance. For example, in a geometric database you might have an object class called polygons, and one called rectangles, where rectangles are a subclass of polygons because every rectangle is a polygon. Therefore it follows that everything that works for polygons automatically works for rectangles too. That's a good idea. But I want to qualify that a bit.
First, if you're talking about pure objects - encapsulated objects - we've already said that means you can only operate on them by means of the defined operators (the OO term is "methods"). When you're talking about subclasses and superclasses and inheritance, we're only inheriting operators. Not structure. There is no structure as far as the model is concerned. You mustn't confuse type and representation. The only structure that's around is representation, and that's part of implementation and not part of the model.
If under the covers, the representation changes - if polygons are represented by a sequence of points for the vertices, and rectangles are represented by just the bottom left and the top right corner or something like that - the code to implement the operator has to change too, but that's implementation. From the model's point of view, if you have a function called area that returns the area of a polygon, automatically it means that you can invoke the area function on a rectangle and get the right answer. Under the covers, it may be desirable to reimplement that function. I don't care. That's implementation.
Inheritance is a good idea, except, when you really poke into it, there's isn't really a good model yet. At least there's not a universally accepted model. When I was first learning about this stuff, I was reading another book and got to precisely this topic. The author simply says that there's no universally accepted interpretation of what inheritance is all about, so I'll just give you eight - eight! - candidate interpretations.
What are some of the problems you can get into with inheritance?
Suppose you have a superclass of ellipses, and a subclass of circles. The first question is, have you partitioned the set of ellipses into those that are circles and those that are not, or have you partitioned into those that are known to the system to be circles and those that are not known to the system to be circles? Is it circles versus not-circles, or circles versus maybe-circles?
An ellipse has two semi axes, a and b. A circle has a radius. Basically, an ellipse is a circle where a equals b. The next question is, does the system know that? Does the system know that in a circle, a is always equal to b? Or does it know that if a equals b, then it is a circle? Does it know both of those, or does it know neither of those? If it knows that an ellipse where a equals b is really a circle, suppose I take an ellipse where a is not equal to b, and I update it making a equal to b, does it change its class dynamically?
These are the kinds of question that have to be answered in any formal model, and the problem is that different languages and systems do different things. As Bruce Lindsay of IBM said in a recent talk, there is no good model, there's just a collection of favorite methodologies. While it is clear that the idea is intuitively attractive, we don't feel it's yet robust enough to incorporate into a formal model such as we're seeking with The Third Manifesto.
At the moment, the document says something like, if inheritance is supported, then that inheritance shall be in accordance with a generally agreed model. And "generally agreed" means that the authors of this manifesto have to agree too! In an appendix, we do make some proposals for a formal model.
Another way to think about The Manifesto is that we're trying to clarify certain parts of the relational model. The model has evolved over the years. Ted Codd's original paper was a work of genius, of course, but he didn't get every last detail right. There are lots of t's to cross and i's to dot. We're also doing some of that in The Manifesto.
We touched on the subject of views earlier in our discussion. This seems like an area where current relational implementations are lacking...
It's one of my pet peeves. You read the SQL standard and other documents, and you find phrases such as "tables or views." A phrase like that clearly implies that the writer thinks a view is not a table - that they're two different things. The whole point about a view is that it is a table; just like in mathematics, where the whole point about a subset is that it is a set, so you can do the same kinds of things on a subset as you can on a regular set. A subset is a regular set.
People who say things like "tables and views" are not thinking relationally. As a consequence, they're likely to make mistakes in their database designs. They're likely to make mistakes in their application designs. And they're likely to make mistakes in the design of SQL itself, which has clearly happened.
There's a very nice analogy between a database and a logical system like the system of Euclid. In a logical system, you have axioms that are given truths, and then you have theorems that are further truths that you derive from the axioms according to certain prescribed rules. In a database, the base relations given truths. The views and everything else you derive are like the firms you derive from the given truths. The base relations are like the axioms of the system, and derived relations are like the theorems you derive from the axioms.
In fact, a database is a logical system. In a logical system, the choice of axioms is often arbitrary. There may be multiple different sets of axioms you can choose, providing the set of theorems you can prove from the axioms is the same. Providing those different choices of sets of axioms are all equivalent in this sense, it doesn't matter which ones you choose. Same deal in a database. The choice as to which relations you make the base ones, and which the views, is arbitrary. As a trivial example, you might have employees and you might have a base relation containing all the employees, and you might have East Coast Employees and West Coast Employees as two views. Or you might have the East Coast and West Coast Employees as two base relations, and derive the union of all of them as a view. It's completely arbitrary.
Consequently, since it is arbitrary, the updatability of the database must not depend on the way you happen to design it Updatability is a semantic property, and the implication is, of course, you must be able to update views properly. For example, the database administrator should have the freedom to make changes from time to time, and say this used to be a base table, and now I'll make it a view. This used to be a view, and now I'll make it a base table. Changes like that should not affect applications.
With correctly implemented views that provide complete updatability, why expose users to the concept of "base table"?
For the same reason you have axioms in a logical system. You have to start somewhere. The point is that there may be multiple different starting points that are equivalent. But you have to start somewhere. You can't take Euclidean geometry and have it spring from nothing. There have to be some given truths, and then there are further derived truths. It doesn't matter which ones you take as given, as long as it comes out the same in the end. At a certain level of the system - and perhaps this is your point - the user sees the database made up of tables. To that user, it should make no difference whether the tables that he or she sees are base tables or views. No difference at all.
We've always known how to do this for retrieval, the difficult part is updates. This is another thing I've been working on recently. Last year, David McGoveran and I came up with a new view-updating algorithm, which we're very happy with. In a blinding flash of insight, we suddenly realized how to update a much wider class of views than has been traditionally regarded as updatable. (The products today don't do this very well at all.) The key point is very simple: So long as the view is information-preserving, it should be updatable. Even things like Cartesian products, which have previously never been considered to be updatable, we say are updatable.
The key insight has to do with what I said about every relation having an associated predicate, which represents what the relation means in a formal way. The predicate for a relation is - logically speaking - just the and of all the integrity constraints that apply to that relation. A relation must never violate its own predicate. That's a sort of axiom. The rule is very simple: When you do an update, the update must not violate the predicate for that relation. Once you understand that point, suddenly it all becomes crystal clear. You can talk about a union of two relations, and you know the predicate for this relation and the predicate for that one. You insert a row into the union. Question: Which of the two components does the new row go into? It depends on the predicates. If it satisfies the predicate for A, it goes into A. If it satisfies the predicate for B, it goes into B. It might go into both, but I don't think I want to get into that right now!
Vendors, and consequently users, seem to misunderstand the difference between the logical and physical levels of a relational database system. Can you clarify these terms?
From a theoretical point of view, the distinction has always been very clear. The relational model is, if you like, an abstract machine. It prescribes that certain things have to be visible to the user, and certain operations have to be available and work in certain ways. Period. How that is implemented under the covers is deliberately not prescribed in the model. It gives the vendors lots of freedom to compete on how well - how efficiently - they can implement these abstract ideas.
It's exactly the same in the programming languages world. Take a language like Fortran, PL/1, Cobol, or whatever; you can think of those languages as abstract machines. We have no problem in that environment with understanding the difference between the interface and the implementation. You can think of the relational model as a very abstract programming language. We're just prescribing objects and operators. That's what the machine has to look like to the user. Now, Mr. Vendor, implement this however you like.
The trouble is, I think a lot of the people who built the relational systems may be very good systems programmers, but they didn't understand the relational model very well. And they didn't understand these levels of abstraction. Consequently, some of the physical things show through to the logical level. That's true of just about every product I can think of that, in turn, has very severe implications for portability, not to mention productivity.
One example might be placing indexing keywords in create table statements...
Yes. Exactly. Or free-space allocation on create table, and things like that these make the statements very nonportable, and there are worse examples than that. For example, in DB2, you can take a large table and partition it for performance and utility reasons. There are good reasons to do that, but the partitioning should not show through to the application. But it does in some ways, because if the partitioning is on the basis of department number, say, you can't update the department number because it might change the partition. Something down at the physical level impacts your logic. That's the kind of mistake that should never have happened if people had understood this clear separation. Mind you, if the relational vendors and users are confused about physical versus logical, then the object folks seem to be confused about it in spades.
I read a book on object-oriented database a few years ago, and there was a very long chapter on "The OO Model," and another very long chapter on "Implementation." The model chapter contained much that was really implementation. The implementation chapter contained much that was really model. It's obvious that object-oriented has come from a programming view of what database is about. Or, you might say it's an engineering view of what database is about. Thus, many of the ideas that the database folks have learned in a very careful and difficult way over the last 25 years have largely been overlooked in the OO world.
What is the greatest misconception about relational technology?
The biggest misconception is that SQL is the same as the relational model. In fact, when people look at relational products, they see SQL products. Not unnaturally, they assume that SQL and the relational model are the same thing. They can't really be blamed for that. But the fact is that they're not the same thing. As a consequence, all the shortcomings of SQL are regarded as shortcomings of the relational model. The biggest shortcoming of SQL is that it doesn't implement the relational model! Consequently, the relational model is, criticized for the very fact that the vendors haven't implemented it. It drives me crazy. Precisely because of that big misconception, we get into what we've been talking about already, namely that relational technology can't do object-oriented kinds of things. It could, if it was implemented right.
When the object folks point their finger and say to the relational folks, you can't do X, that may be true if you take today's products. I'm talking about what the technology ought to be like. Not what the products are actually like.