Slashdot Mirror

One thing that annoys me is the disjunction between UPDATE and INSERT queries for the same set of fields:

INSERT INTO blah(uid, name, email) VALUES(12,'Goober','goob@example.com')

But if you want to change that to an UPDATE query, you have to move each of the fields around:
UPDATE blah SET uid=12, name='Goober', email='goob@example.com'

This would have been better:
UPDATE blah SET (uid, name, email) VALUES(12,'Goober','goob@example.com')

By the way, if you want to read hard-core fundamentalist, pro-relational stuff by DB guru CJ Date and others, DBDebunk is the place:

http://www.dbdebunk.com/

One should look at C. J. Date's papers on the LSP (WHAT DOES SUBSTITUTABILITY REALLY MEAN?), before they try to implement it.

Code that implements e.g., squares that aren't rectangles or circles that aren't ellipses, is taking a shortcut or overcoming a technology flaw.

Are there any Relational databases available commercially? That is, a DBMS that actually implements the relational model? Not flaming, I genuinely want to know.

Here's an interesting site on the subject: DB Debunk.

This sort of crap was dug up when "object-oriented databases" were invented,

Every little while somebody who doesn't even understand relational theory suggests that relational databases aren't "necessary", "efficient", "legacy", or some other crap.

Here are the facts: short of some sort of AI conceptual processing being developed, relational databases are the ONLY known method to CORRECTLY reflect the realities of modeling the real world as data (and even then there are problems.)

Go talk to C. J. Date or Fabian Pascal - they'll set you straight on that nonsense.

Go to the Database Debunkings site and learn something.

Well, some people hate it http://www.dbdebunk.com/index.html, but SQL is far more powerful than FP, if you agree that declarative languages are better suited to the task of manipulating data.

FP is a clone of dbase, which had nice features to handle data only if you compare it to a bare C API.

SQL is the most popular implementation (definitely not the best or purest) of tuple relational calculus.

Finally, speed is not related to a particular language but to its implementation. How a query is carried out is the task of the Query optimizer http://en.wikipedia.org/wiki/Query_optimizer. I don't know anything about rushmore technology, but I don't think it goes beyond the query optimizer concepts that predates that technology by several years.

There are some fishy things here.

One is that WinFS was not promised for now: it was promised for, say, 15 years ago. MS Access was said by Microsoft to be a first step towards a totally relational OS really soon then. Just as Cairo (MS Windows NT 4) was supposed to be totally OO, and now we are told native code will still be with us for several years yet.

But the worst thing is that they don't understand what they intend to ship. WinFS is not relational, not it can ever be, since being based on (a bastardised version of) ISO SQL it violates the basic fundaments of the relational model. Incidentally, this non-relationalness makes it much larger, less performant, more complex, less powerful than it should be. Coincidence?

With all the negative posts by AC's on Celko, I just had to recommend that folks read the reviews on Amazon before writing off Celko's books.

I like the guys on DbDebunk (the site referred to in several of the anti-Celko links), and I recommend their books as well, but I wouldn't recommend their books or their site as the best place to learn practical SQL. But, check out their site and decide for yourself.

Would someone please point me to some text books alternative to Celko's? In particular for schema design.. tnx

You can start here.

It is not a new relational theory, but it is (claimed) to be a proper implementation of relational theory. Oracale (and all other DBMS vendors) implements a bastardization of the relational theory.

That's because you're hanging out with the wrong kind of geeks.

You have to hang out with the guys that geek out on getting laid.

Did you know there have been people working on a general algebra for data management for, what 40 years now? Did you know, this is basically a SOLVED PROBLEM? Ever heard of "D"? Or Tutorial D? The Third Manifesto?

You know, I totally understand why Fabian Pascal is always pissed off.

Here's something for you to chew on:

Why do programmers write this:

A + 3

when they want to add 3 to A? Why do we not write some lovely crap like:

OPERATE ON A WITH 3 USING ADDITION

why do we write:

(A + 3) * 2

and not:

OPERATE ON (OPERATE ON A WITH 3 USING ADDITION) WITH 2 USING MULTIPLICATION

Why do we do that?? Because algebraic notation is 1) declarative .. it tells the computer what you want, it doesn't tell it how to do it and in what order, and 2) algebraic notation is *completely general*. You can nest arbitrarily with parentheses, and you can clearly see what's a variable and what's a value and what's an operator. Easy to create, understand, and *optimize*.

Do you agree with me that the verbose syntax clouds your thinking? Keeps you from seeing the underlying operations? Makes it difficult to apply the basic algebraic skills you learned in high school? Makes it difficult for the compiler writer to do the same?

Now I ask you, why do we write:

SELECT * FROM Order

and not

Order

Why do we write:

SELECT * FROM Order JOIN OrderItem WHERE Order.order_id = OrderItem.order_id

and not

Order JOIN OrderItem

And here you are, dwelling on some little detail about projecting columns.. this is an easy one: use an "ALL BUT" operator for example:

RelvarWith100Attributes ALL BUT (Attribute100)

Once you see that relational algebra is just values, variables, and operators nested in any arbitrary way, just like arithmetic, you have opened the door a little more to understanding the fundamental theory of data management and how backwards and primitive "modern" data management is.

And let's not even get into all the crap that SQL gives us like duplicate rows, NULLs, brain-dead table-oriented storage, lack of 100% updateable views, lack of arbitrary constraints, (often) lack of composite types (why the hell do we splat objects into MULTIPLE COLUMNS?? They should be stored in ONE column). SQL also confuses logical and physical layers (keys vs. indexes), and has basically kept the database industry in the dark ages for decades now.

So the answer to your question is pretty simple: I would ditch SQL and use something that looks like relational algebra, which has been understood and documented for a probably longer than you've been *alive*. No offense.

I second the recommendation for C.J.Date's book. After you finish reading that one, here are some more, from Date, Darwin, Pascal, and other standard bearers of the relational model.

HCI's not in the Stone Age; it's in the Industrial Age.

There has been *no* innovative research done in HCI since the Mac UI guidelines.

Guys like Tognazzini and this guy just like to make laundry lists of their complaints and harp on Fitt's "law." (I guess "law" sound better than "tautology.")

My basic complaint boils down to this:

These guys think like industrial era efficiency experts. Now, if people who used computers came in at 9 every day and left at 5 and did essentially the same set of tasks for months on end, many of their assumptions would hold water.

It would make sense to have them use corners of the screen. It would make sense to memorize arcane "gestures."

But most people I know face a completely different setup:

Someone else sets up their computer or they often have to use other people's computers. They often have to do other people's jobs, or they are changing jobs quite rapidly.

Moreover, they spend an extraordinary amount of time copying and pasting (or retyping) data from one app to another. When something changes, they have to update it in multiple places.

My analysis is simple: our applications and HCI people are too focused on visual representations of data. So most of what HCI does is nothing more than put an odometer on the mouse.

We need to focus on the logic of the data itself (data fundamentals!) and the way the people learn interfaces.

As it is, the way we're using computers is directly analagous to the way we use paper. That doesn't exploit a fraction of the power mathematics and machines could give us.

The language Tutorial-D in the article you refer to is yet another language for relational databases! Darwen and Date are critics of SQL implementations; they are NOT critics of the relational database as you imply. They are instead the strongest relational database proponents.

Indeed the relational model is the only model with logically provable underpinnings. In ON DOCUMENT- VS. DATA-BASES Chris Date explains:

Types are things we can talk about. Relations are sets of statements that we can utter about those things. What can you do without the latter? The problem of OO is that they have just types, no relations.

And about "document databases" (this would include HTML & XML):

A document mixes data with layout (presentation). Databases deal with the former, intentionally leaving the latter to applications. Furthermore, the structure of the document is not such that it lends itself to the kind of inferences that are made from databases. What is the atomicity, selectivity, and correctness for a document base?

Just to reinforce recommendations others have made...

It's been years, but for me, simultaneously struggling through Date's Intro to Databases to understand the theory and Celko's SQL For Smarties to understand SQL did the trick.

I did not not like Hernandez's (sp?) book database design for mere mortals. Although I appreciate the author's consulting approach, I prefer to develop my understandings on the more theoretical works - such as Date's work. I also like Date's aggressively opinionated style - check out his website database.

How many times have I read database articles that says the same damn things through a thick and wooly fog of imprecise language and confused concepts, offering absolutely nothing: 1) the world is different now 2) the relational model is dead 3) XML, objects, blah blah blah.

We live in a time of extreme change, much of it precipitated by an avalanche of information that otherwise threatens to swallow us whole. Under the mounting onslaught, our traditional relational database constructs--always cumbersome at best--are now clearly at risk of collapsing altogether.

*sigh* Where to begin? First of all, the relational model is just that: a model. In fact it's safe to say that it's the model for data storage and manipulation, since nobody has presented one that's 1) more general and 2) doesn't reduce to the relational model. Clearly what the author is referring to are current poor implementations of non-relational SQL-based database applications. Normally, a knowledgable person should stop reading. But let's continue. Perhaps, even with poor wording, he still has something to offer. Even if it's just more quotes of the week.

Aside: has there been any time in modern history when we weren't in a time of extreme change, and there wasn't an onslaught of information? Why were databases invented in the first place?

Accordingly, the modern database system increasingly depends on massive main memory and sequential disk access.

This was a particularly funny quote.. what did they depend on before?? The printer?

now because databases have become the vehicles of choice for delivering integrated application development environments.

Another great quote! Databases are used to deliver IDEs?? What is he selling? Maybe he meant applications, not application development enviroments, but that doesn't make sense either.. applications have always been about data + algorithms + UIs.

Now ... business logic can run inside the database. Active databases are the result, and they offer tremendous potential--both for good and for ill.

Good lord.. hasn't he ever heard of a constraint? A stored procedure? A user-defined function? Column types?? That's business logic! At least he got some new terminology out of it: "active database". I'm now confident predicting that this article will consist mainly of coming up with new names for old things.

The really big news here is that these languages have also been fully integrated into the current crop of object-relational databases. The runtimes have actually been added to the database engines themselves such that one can now write database stored procedures (modules), while at the same time defining database objects as classes within these languages.

What does any of this mean? What was I using to write stored procedures before? Why are you calling them "modules" now? What is a "database object" and how can you define an "object" as a "class"? I thought a class was a template for an object?

With data encapsulated in classes, you're suddenly able to actually program and debug SQL

Anybody remember this TV commercial: "When pizza's on a bagel, you can have pizza anytime". I don't know what that meant, and I don't know what he means here either.

Now, fields are objects (values or references); records are vectors of objects (fields); and tables are sequences of record objects.

Yup, I was right... let's rename everything, that makes it new and fresh! Fields are now objects, values, or references.. records are now vectors and tables are sequences (is that different than a vector?). And somewhere in th

That's why they're using XML. It allows for more data to be available.

LOL

That's awesome. I gotta save that as a quote. Maybe I'll send it to DB Debunk.

Don't mean to pick on you but really that is hilarious. Who knew that my data bottlenecks could be solved so easily by switching to the miracle of XML!

> If you don't think SQL is relational

It ain't no matter what I think, but it still is better than anything else in widespread usage today.

> you certainly won't think IMAP is, but you can do more than most MUAs support.

That's the question.

On changing column types, although most RDMS systems let you do it, and in many cases do so without requiring you to delete and recreate the table, a conflicting type can be a problem.

The people working on XML Query are not ignoring the history of relational databases. Heck, the language is edited by the co-inventor of SQL itself, the the Working Group chairs have been involved with (and edited) the ISO SQL spec, SQL/MM, SQLX, the JDBC and others.

I second this. Also see here.

Before perusing this discussion, you may want to get some perspective by reading Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments by Justin Kruger and David Dunning (Journal of Personality and Social Psychology,

Well, I didn't know much about this guy. But anybody who defends his position by referring to this psychology paper doesn't score too high in my book. If you're not familiar with the paper, it basically asserts that stupid people don't realize how stupid they are. So referring to this paper is a subtle way of saying "you're stupid, and you don't know it".

But I'll give him the benefit of the doubt.. after all some other pompous experts have referred to that paper yet raise important points based on sound theory. I.e., there is not necessarily a correlation between being an assmunch and being *wrong*.

So now I read his papers on getters/setters and he claims this is "bad" because it assumes an implementation of the underlying value:

double orderTotal;
Money amount = ...;
//...
orderTotal += amount.getValue(); // orderTotal must be in dollars

Excuse me but having to declare orderTotal to be any particular type is a *JAVA* thing, and not universal to OO programming. In Ruby for instance:

orderTotal += amount.value

No types or assumptions here. Since Ruby is fully OO, this will work even if amount.value returns a Fixnum, a Float, or a SomethingElseEntirely.

He says a "better" way is:

total.increaseBy(amount );

But this is just syntax. In Ruby I would just write:

total += amount

And it doesn't matter what the types (classes) are.

Poor guy is stuck in a statically typed Java hell, with distinctions between primitive types and objects, of course he's gonna think getters/setters are evil and he's gonna become obsessed with keeping his data hidden in a box or behind opaque methods! I can just imagine his code filled with thousands of builder objects with 2-3 levels of abstraction .. and it will just be a grotesque simulation of a true dynamic language in the end, with everything completely decoupled.

I don't know if I should bother reading any more of his writings since I don't use Java.... is the rest of his work "how to get around Java's shortcomings" or is there something a general purpose OO practitioner might find useful???

Readers interested in what Pascal and Date have to say may be interested in visiting Database Debunkings. It has lots of articles written by one or both of them.

Personally, I recommend the articles written by Date because they are clearly, concisely, accurately, and calmly written. Pascal's tend to turn into a rant, which I wouldn't mind but he always seems to refer to his books rather than give a detailed justification of his arguments.

> SQL: Standard Query Language

Structured Query Language.

> for querying relational databases

SQL is not relational. It violates several principles of the relational model. The ISO SQL standards don't even mention the relational word since at last ISO SQL:1999.

> "SQL database" is a meaningless phrase.

It ain't. An SQL database is a database created and manipulated with ISO SQL. An SQL DBMS is a DBMS creating and manipulating SQL databases. You can even speak of SQL data, meaning data structured with SQL.

While on general lines I agree with the article, he clearly misunderstands WinFS -- the effect might still be the same, as either MS itself is misunderstanding WinFS, or at least selling it badly.

WinFS, or files on a SQL -- not relational -- database is not about organising for search, but about not having to organise, yet being able to.

With current hierarchical filesystems, we are forced to organise files hierarchically, and that's very often cumbersome. So search functions have to dig into each document and kinda Google it, building a full-text index, and that takes lots of resources and is difficult to do. Not even Apple does it good enough, at least it didn't in my then-Mac OS 9 366MHz iBook.

With an SQL database as the filesystem, even if SQL is so inferior to the relational potential, we get rid of the necessity but not of the possibility of hierarchies: we can still put some or all of our files in hierarchies, but now the specific nodes in the hierarchies where the file is are just some more attributes, so any file can be at several places at several hierarchies, or at none at all. Searching too becomes more efficient, but the real benefit is alternatives to organisation, and therefore the possibility of richer queries and easier remembering.

It couldn't be, since SQL ain't relational...

First, SQL additionally supports lots of things that are deliberately excluded from the relational model (pointers are a good example), so it lets you to do lots of nonrelational things--a fact that introduces a great deal of complexity, though it doesn't add any power (you can't do anything useful with those nonrelational features that you couldn't do without them).

Second, there are some relational things that can be done in SQL only with a great deal of circumlocution. Try writing a relational comparison in SQL, for example, or an SQL constraint to express a general join dependency.

Third, SQL is an extremely redundant language, in the sense that all but the most trivial of queries can be formulated in literally thousands of different ways: another fact that makes life extremely difficult for the poor old user--and, likely as not, means the user has to get into performance issues, since those different formulations will almost certainly not all have identical performance characteristics. [Ed. Note: In 1987 I published in Database Programming and Design the results of running the same query expressed 7 different ways against 5 different SQL products and got response times ranging from 2 seconds to 2500 seconds!!! Since then SQL has become even more redundant.]

Fourth, never mind that SQL was originally meant to be a language for dealing with relational databases specifically--the fact is, it's pretty badly designed considered simply as a language. I mean, there are several well-established principles of good language design, but there's little evidence that SQL was designed in accordance with any of them. As a consequence, its syntactic and semantic rules can be very difficult to learn and remember. For example, do you know the rules for writing join expressions and/or union expressions?--which, I can't help adding, are not just different from each other but almost completely different. E.g., A NATURAL JOIN B is legal but A UNION B is not, while SELECT * FROM A UNION SELECT * FROM B is legal but SELECT * FROM A NATURAL JOIN SELECT * FROM B is not.

"As for your manipulations, they're only declarative if they're expressible in the logical model... And mine are NOT!"

But they are. See next response.

"The constraints that I'm talking about are precisely the tree structure itself, the form of nodes and their linkage"

Given a set of nodes and linkages you can easily generate a logical model:
Tree( Link, Node_Data (whatever that may be), Parent, Level )

I can't really draw a picture but maybe this will help (taken from Pr

"The relational model is not set theory, it's the relational calculus."

Nope, read Codd's paper if you don't believe me.

Basically the RM is (taken from DBDebunk.com):
Theory: predicate logic and set mathematics
Structure: R-tables (precise definition!)
Integrity: domain, column, table and database integrity
Manipulation: R-operations (restrict, project, join, etc.)

"What more I want is to manipulate my data, not just represent it!"

The relational calculus of which you spoke is one way to manipulate it! That's the "Manipulation" part above.

"In my example it's precisely my point that the different nodes cannot be in the same relation"

What example of business data would require you to store different entities in the same relation?

"you lose the ability to manipulate your data in the form is actually takes."

The RM is a logical model -- if you were a DBMS maker and you really wanted to implement (e.g. on the physical level) a hierarchy as a series of nodes and pointers you can. However, from an application standpoint you don't need to store the hierarchy in any other fashion.

Tell me -- how do you apply constraints and business rules to your tree in your example? Procedurally, and "by hand" (e.g. you have to code your own rules). The RM provides for declarative constraints AND declarative manipulation tools which are far simpler than the procedural counterparts (and as we all know, the simpler the better, less buggy, etc.).

"You said that there are no graphs that have cycles"

That was a mistake on my part.

Can you describe the problem using predicate logic and set theory? If so, you can model it relationally.

There's a chapter in "Practical Issues in Database Management" which illustrates how a RDBMS should handle hierarchies (e.g. trees as in your example) and how, stuck with SQL products, one would do it in SQL.

> Why relational databases?

Because there is nothing else good enough.

> Why not a post relational design?

Because there is not quite such a thing... all are actually worse, lacking the fundamentals.

> Why not an object oriented database?

It is a 30-years throwback to pre-relational systems.

> Everything doesn't map cleanly to the relational model.

You are thinking SQL. The relational model really can map anything.

> see PickOS, a relational DBMS built into the operating system

Pick is MV, not relational. Check news:comp.databases.theory for more on that, or DBDebunk.

> What do you mean by relations?

Like in Mathematics. Really this is not the place to teach that, I recommend Chris J Date's books as listed at DBDebunk.

> you're probably trolling

Am not.

> with the 5 name name

Old Portuguese tradition, plus my mother didn't want me to have troubles with sharing the same name. Really.

> the need to advertise your profession on slashdot

Why is that a problem?

> I couldn't just read these things you wrote as statement of fact without bothering to provide any explanation or evidence.

I won't do anyone's homework.

> maybe not

Only if inertia and ignorance continue to hinder us.

> here are some performance issues

No, this is a physical issue. The relational says nothing about the physical level, thus leaving the implementor total freedom to achieve the best performance possible. This is typically better than what is possible navigationally.

> even if the relational database uses a raw partition it is still use some sort of filesystem

Not at all. What makes you think so?

> how do you know ti will be a realtional database? Maybe it will be an OO database.

OO has already been laughed off the contest.

Correct. Have a look at database debunkings to see why SQL DBMS != relational DBMS.

You know what? Forget Grandma. Spending all this effort on a desktop that, quite frankly, looks like the worst goddamn thing I've ever imagined myself using, is a huge waste of effort.

My grandma, an intelligent woman, can't use the remote, can't use the VCR, can't use email, and sometimes can't even turn on the TV, despite hours of patient training and careful organization of screen icons, remotes, and so forth. Don't waste your time.

If all this effort was spent on a new way to think about file systems and file organizations, maybe we'd get somewhere. I'd like to see the open source community out-Longhorn Longhorn, for example, before the goddamn thing even shows up. I've always thought a relational or cross-indexing metaphor works best anyway. We abandoned hierarchies in the 70's, for chrissakes, when we dropped CODASYL on its ass.

> Content-based products like a website or CMS should add information architecture.

Ma ze? Que isso? Qu'est-ce que c'est ca? What's that?

Yet another buzzword for DBAs and data modellers to make for the general lack of understanding on data fundamentals?

> I thought that SQL was the embodiment of the relational calculus?

The Third Manifesto, DBDebunk, DMoz.

> Can you (or someone else more clueful than I) explain it again in a manner assuming less cluefulness on the part of the reader?

I really haven't the time. About data I'd point you to some reading materials: the books mentioned on The Third Manifesto, DBDebunk, some articles at DMoz and an implementation with documentation; about OSs, the GNU Hurd site seems to be unreachable now.

More insightful information on the differences between SQL-DBMS and R-DBMS is on DB Debunk
OT: Have to post AC, have been modding.

SQL is not relational. Its tables are not relations, because relations are sets, and sets don't contain duplicates.

There are several other reasons why SQL (and therefore derived products) aren't relational, check Database Debunkings for more info.

I couldn't stop thinking of existing theories and/or implementations of her ideas...

Modeling processes out of the OO paradigm (opposite to what Design patterns started to sacralize for example) is precisly the subjet of so-called business rules. But BR people are close to relationnal model of data, that is too quickly assimilated with SQL DBMS(*), so OO oriented people don't buy it (see the almighty impedance mismatch).

Data-structures other than trees and collections are already genericaly implementable in any modern OO language. See Eiffel for example which can perfectly do that for 15 years (parametric classes, with full type safety). May be the java generics will help to build highly reusable data structure... I doubt that, anchored type is missing (ie the possibility to declare the type of a variable as equal to another type, nearly mandatory when dealing with inheritance of generics).

Tom.

(*) I warmly recommend the writings of Chris Date and Fabian Pascal to really see how the relationnal model of data is different from SQL databases...see DBDebunk for references.

A, yes true, but does it really matter? As others have stated, you don't ALWAYS need to have extremely small, efficient, fast, etc. code/programs/information/etc.

WHAT!?!?!? Since when is it acceptable to WASTE computing resources JUST BECAUSE? You certainly are not someone who has to manage any sort of large-scale system (be it a network, or a DBMS, or a render farm, etc.).

We're talking about a protocol that, potentially, tens of millions of people will be using. I think it would be important to CONSIDER optimization.

XML has been PROVEN to be a superfluous format, one which poorly or incompletely solves problems which have already been solved.

No, he is not trolling. He has asked the only deeply relevant question in the thread.

"Why?"

And it turns out there's really no good answer other than just taking a ride on the buzz train.

On the other hand there are a ton of reasons why XML stinks to high heaven as a musical notation format.

You'll find a short but humorous look here:

Music XML

Now here's an example of a plain text encoded note that I just semi made up on the spot:

g"4

Human readable. Machine interpretable. And musician readable. A violnist could learn to sight read a score in this format in a matter of minutes.

I doubt a violinst could parse the XML for a single note. Hey, but at least the code takes up a quarter page.

If you need any clue as to how valid XML is for this sort of work consider the fact that people are making hardware XML accelerators.

For plain text files.

I'm sorry, but could you please stop the train? I want to get off.

KFG

> A RDBMS for storing user data is nice, but do you want your /sbin or even /usr/bin stored in an RDBMS?

Why not? Provided the RDBMS is the primary storage component in the database. Speaking of that, not only storage: memory could also be organized in a relational manner.

In the end we'd have a situation similar to Lisp hackers' relationship with Emacs: the RDBMS is my OS, [Linux|Hurd|BSD|whatever] is my microkernel. Nicest of all is that we could even have a relational, functional ([Lisp|Scheme|ML|whatever]) language in the same level occupied by C and libc in POSIX.

> Even with a true database-based system, there has to be a decent way to organize binaries outside of the database.

A relational system would be able to efficiently give any file any number of locations in any number of hierarchical namespaces you choose to.

Just remember SQL is enough, SQL not being relational.

E.F. Codd: In a relational database all data should be represented explicitly and in only one way, as values in tables.

The very IDEA of a "Null value" is not only contradictory to this idea, it's outright silly. You can not represent an "unknown value" in a relational database where "all data should be represented explicitly and in only one way". You can not, logically, represent the "unknown" in only one way. Rather, it's more like saying "this could be anything, but it's only one thing, which is not necessarily the same as all the other one things, that could be anything but might be the same as this one thing".

In other words, it's ridiculous to even use a "Null value". If you don't even know what it is your representing, why are you trying to represent it?

That's only one example that peeves me in particular. Go check out Fabian Pascal's articles and Database Debunkings for a heck of a lot more thorough and eloquent justification on the position than I could rehash here.

The relational model, as invented by E. F. Codd, is heavily grounded in mathematics and set theory, and exists independently of higher-level access interfaces such as SQL.

You can certainly teach people to create and use databases through Access or SQL, in the same way you can (to pick a randomly politically incorrect analogy) teach people to create bombs without telling them how chemical reactions work, but then you're not telling them the full story.

Knowing what a Cartesian product is, or what normalization and the five normal forms are, or what relational integrity is -- all that lets you design better, more flexible and extensible schemas, and interact more intelligently with your data. I know Access developers who don't have a clue about the relational model, and as a result design terrible applications.

As a starting point, I recommend the books by C. J. Date, in particular An Introduction to Database Systems, 7th Edition ; his book The Database Relational Model: A Retrospective Review and Analysis: A Historical Account and Assessment of E. F. Codd's Contribution to the Field of Database Technology also looks very interesting.

As an aside, what's surprising is how many people consider Codd's original ideas outdated. The fact is, his ideas surpass what's implemented in database systems at the moment. SQL is a weak language (and SQL99, with its silly object orientation extensions, hasn't made it any better). Database vendors routinely expose underlying implementation issues to the user. They tightly couple physical representation with logical representation, leading, for example, to many people avoiding normalization because it incurs a significant performance penalty with most databases. RDBMSs today are crap.

For every point you make I can illustrate two which are perversely backwards.

For example, Oracle was one of the last DBMS products to include a cost-based optimizer, something Sybase ASE/MS SQL Server/DB2 had long before.

For the longest time (far longer than competitors) Oracle's method of backing up and restoring databases was a three-day course.

Oracle has all but eliminated the standard 'VARCHAR' data type for the non-standard VARCHAR2 (and other *2).

Oracle's optimizer, through 8i, was insanely stupid for many queries that involved joins. Updating statistics (for index selection etc.) is still significantly more difficult and cumbersome than competitors.

Oracle 8i and 9i requires significantly more DBA resources to administer than other DBMS's.

With so much emphasis on 'self healing' (which still requires a significant amount of DBA intervention) you think that it would become easier to administrate, but I guess not.

Of course, I don't think Oracle is a crappy product. Working with it pays my bills - but God's gift to the world it aint.

If they truly wanted to innovate, they'd implement more of the relational model and save a lot of headaches from both end users and DBAs!!

to quote Fabian Pascal:
The problem is that those who say 'right tool for the job' are usually those who have no clue what the job is -- they only know tools and how to apply them mechanically.

Which means the vast majority of practitioners.

And I, and others, have pointed out XML is a horrible data storage format.

• 1. First is that it re-implements an http listener. Alternatively Zope works with Apache through a sort of CGI (CGI? Today?). I'd rather use Zope with Apache through some sort of mod-zope, like Tomcat.

Zope's HTTP listener is optional. If you want to use a server such as Apache as the HTTP front end, use FastCGI (mod_fastcgi). Despite the name, though, FastCGI is not really CGI as you know it, although it does require that Zope is running separately from Apache.

However, Zope is a publishing engine mostly based around HTTP. Almost every part of Zope assumes that HTTP is on the client end. And that's all well and good, considering that HTTP is the core of the web. And it hasn't stopped the Zope people from supporting XML-RPC and other access methods.

• 2. Also, I don't like ZODB - another reinventing the wheel while there are good open source databases. Besides, ZODB is a sort of ODBMS ...

The ZODB is an ODBMS: It's an object-oriented database management system. Zope is an object-oriented system and relies entirely on the underlying OO persistence characteristics of the ZODB system.

With an RDBMS, Zope would have been forced to add a significant translation layer between its object file system and the logical database. Such translation -- usually known as object-relational mapping -- incurs much performance overhead, and is potentially awkward, since it needs to bridge between two fundamentally different data models.

• ... while I think ODBMS is a techological dead-end, even more dead-end than RDBMS. ORDBMS is the only way to go, IMHO. Thanks to PostgreSQL, there is an open-source ORDBMS.

Whatever marketing hype it is you've been smoking, consider detox. The ORDBMS is an illusion. Ever used the classes and methods and polymorphism specified by ANSI SQL-99 (aka SQL 3)? No, you have not -- because nobody has implemented it.

Oracle stuffed Oracle 8 with half-baked OO stuff. DB2 has support for tree constructs and multimedia. PostgreSQL started with inheritance and "time travel" versioning, and since they dropped the latter you're left with an esoteric mechanism that's hardly a significant improvement on the relational model.

Oh, and are we really mature enough to be playing around with bad, underspecified, non-standard "object" stuff when in fact nobody really implements the relational model correctly yet and we are still tied to that terrible language, SQL? Not even PostgreSQL is a true relational database in the mathematical sense as invented (or perhaps discovered) by E. F. Codd.

It's true that the ZODB does not support the relational model, but it solves some very specific problems and does it well, unlike ORDBMS technology, which is mostly smoke and mirrors used to describe proprietary extensions to SQL.

• Unfortunately, it's mot possible (or it's not documented) how to get rid off ZODB completely and to use PostgreSQL as the primary DB backend.

You can't get rid of the ZODB per se, but you can switch out the ZODB back end, the storage driver that handles the physical data storage. People have written database back ends that store the database as simple files and in BerkeleyDB databases. Don't think anyone has written a generic RDB-based storage implementation, though.

> the BFS did initially use a full relational database backend

No, they didn't. They had a SQL-like system, but SQL is not relational.

> it performed very poorly

This is an implementation problem, has nothing to do with the data model. One of SQL's failures is exactly confounding data model with implementation, that is the logical with the physical levels.

There is a huge misunderstanding: SQL is corrupted, not derived, from the relational model. Since SQL deviated from it, the relational model has been developed significantly by Hugh Darwen and Chris J Date among and above others.

So MS is not proposing a relational data storage instead of a file system, but a SQL data storage. Or perhaps not even SQL, as MS SQL Server is notoriously almost as little SQL-compliant as Oracle itself, the king of standards deviations, second only to MySQL.

BTW, if anyone tries to tell you SQL is really relational, or quasi-relational, don't belive the Marketspeak. You can't be quasi-Mathematical, and the relational model is really an implementation of set theory and predicate logic. Tables aren't relations, just like 2+2=5 is not Algebra.

Pragmatically, this prevents SQL from being as flexible, simple and performant as a relational system is. There are some examples, unfortunately mostly historical: Ingres QUEL was found to perform consistently better than SQL systems, and much better than pre-SQL systems that had SQL grafted upon; BS12 was much cleaner, as was QUEL, than SQL; nowadays Alphora Dataphor is extensible in a much cleaner way than current OO or SQL OO systems.

In its defense, it may be that Microsoft uses only the data storage engine of MS SQL Server in WinFS, just as it uses it now for Exchange. Getting rid of SQL looses many interesting, powerful capabilities, but also may unleash performance. It even could be perfected as the engine of a future, nice, relational system, if ever Microsoft wakens up to what Alphora and TransRelational are (trying to) do. But I very much doubt; most of the database field, both academic and corporate, is corrupted by SQL money; there simply isn't enough cultural critical mass for a big company as Microsoft to steer its course from SQL to relational.

Even so, this could be the single most important contribution of Microsoft to the Informatics field, on a par with making the x86 computer a commodity. Even a sub-relational system can be so much better than what is around; this, together with Moore's Law making inherent Wintel inefficiencies irrelevant 80% of the cases, could pose a very big threat to the competitive position of free software. Granted the GNU/Hurd, or perhaps even Eros, could implement something even better than WinFS, truly relational and with orthogonal persistence in the physical layer (Eros) and/or a functional language application layer (GNU/Hurd). But there is no talk of doing so yet, and it would take a long time to bring these systems to where GNU/Linux is now.