Re: The term "theory" as in "database theory"

On Jan 26, 2:05 pm, "dawn" <dawnwolth..._at_gmail.com> wrote:
> So, one person might have 2VL in their
> theory and another might have 3VL, right? How would one judge whether
> one was better than another? I would think that would be by applying
> each system of rules along with some means of measuring which system
> produces better results in various areas.

Sure. Yes. Therefore:

Since you're so committed to trying to convince the world that MV is better than relational, what *you* should be doing is floating real-world use-cases, proposing MV and SQL schemas, and writing queries in each system and comparing them. In fact you don't even particularly have to compare them; if there is any kind of significant difference, the comparison will be obvious on the face of it.

If you drift into questions of how to model the domain, you're already lost. The question of whether a pizza with cheese and pepperoni is the same as a pizza with pepperoni and cheese is utterly irrelevant to database theory; pick one and stick to it. When interviewing people I sometimes ask them questions related to designing schema and writing queries for a bank (checking, savings, etc.) but I usually specify that each account has only a single associated customer. Is this realistic? No, and it doesn't matter, because the question isn't "can you realistically gather requirements for a banking application;" the question is how you take a set of requirements and realize them in a concrete design, and write concrete queries against it. Gathering requirements is an important aspect of software development, but it's an atheoretical aspect. (Unless someone out there has a theory of requirements gathering.)

If you drift into talking about 2VL vs. 3VL, then you're already lost. This issue is ortohogonal to the RM; it is a SQLism merely. (In fact, given the importance of value equality to the relational primitives, there is a good argument that 3VL is antithetical to the RM.)

If you drift in to talking about how SQL doesn't have lists, you're already lost. SQL isn't the RM, and lists can be built on top of relations. In fact, lists-as-relations is the preferred description of lists in various math books I've read, even those that have nothing to do with databases or even software.

If fact, if you drift into complaining about SQL at all, you're off track. There are plenty of RM people who will also complain about SQL, and in fact they can probably fault it better than you can. If you want to compare MV to SQL, then do so, but if you want to compare MV to RM, then you have to recognize that SQL is merely a flawed but well-known vehicle for writing relational expressions.

If you drift into talking about how Codd said this and 20 years ago that, and marketing hype the other thing, then you're already lost. These issues have nothing to do with which approach is better, cleaner, more expressive.

If you want to start talking about flat vs. nesting, then you have to compare MV with a *nested* relational model. Otherwise you're not comparing MV and relations, you're comparing nested vs. unnested models.

If you start talking about user interface construction, you're comparing toolkits and not data models.

And most importantly, if you're unqualified to do this, if you can't write the schemas and the queries and put them out there, then you're not qualified to have an opinion on the relative merits of the multivalue and relational data models and query languages. Say what one may about Neo, at least he builds models and writes queries.

Marshall Received on Sat Jan 27 2007 - 19:40:09 CET