The author is misinformed in many ways. To pick an easy example, he says that "the relationship between objects is built into the objects", and as an example cites, "An invoice knows as part of its structure, who the customer is. That pointer to the customer is stored in the invoice."
But that doesn't have to be the case at all. It's common (in general, maybe not with customers and invoices) to store the relationship in a third table, say "customerinvoice", that has customerid and invoiceid fields.
I agree the author is misinformed, though I also agree with him that relational databases suck, especially if you are doing object oriented programming. I'm not sure what is better, however. Also, most of the corporate world is firmly ensconced in the relational database mindset. This makes interacting with them difficult if you do not also "speak relational."
I've worked with a lot of accounting data, which fits the relational DB model really well. But I can't understand why I have to use an OO model to display it on a screen as a table of rows and columns with the odd field scattered here and there. It just seems like a lot of extra complexity to me when all the users want to see is SELECT * FROM TRANSACTION.... made to look pretty.
Funny, that's what my users want, and the only object I use to give it to 'em is a CSV parser that happens to have an output method (which works really well).
Users are delighted that all they have to do is click and their Excel/SAS datasets fill up. They are dumbfounded when I show them the code and it is quite literally 4 lines long, and two of them are MIME headers.
Of course, they don't see the definition of the VIEW, but why should they? ;-)
Indeed. OO is so ill defined anyway. What is documented as OO now I am sure is not what alan kay intended it to be. New popular frameworks like rails don't help either (much) - although its oo-lite - so its not so bad.
still, I am looking forward for an excuse to crack out stuff like arc and walk away from OO for a while (I am allowed to dream).
I've been working with Smalltalk, which was Alan Kay's creation. Most implementations are not what he intended -- at one Smalltalk Solutions keynote he excoriated all of us. He said that he never intended Smalltalk to become a programming language. He wanted to create a Montessori toy for the mind. That said, I don't think that Smalltalk as a programming language is that far from what he intended. He just never intended it to stop there.
Doubtful. Object oriented models mirror the real world far more than normalized relational data.
So then ... maybe its relational dogma that is the problem. People are realizing that it is the source of the object-relational impedance mismatch, and is what needs to change.
This is because businesses learned painfully over many years that the relational model is the simplest way for them to store the data relevant to what they do in a way that is accessible to all of their IT systems that they have or that they might want to build. Relational databases, as they are currently implemented, might be getting long in the tooth now:
http://lambda-the-ultimate.org/node/2500
However, given the relational model's foundation in set theory and predicate logic, it seems you'd be hard pressed to replace it with something else that can offer the same data integrity guarantees.
If you do that (create a customerinvoice rel table) you still have to change your data model every time you want to track a different kind of relationship. We've just converted to a generic relationship table (subject relation object) to handle any kind of relationship, so we no longer need to keep adding tables and changing data models. This is beyond a huge time saver.
I think everyone has considered very lose table schemers before, built entirely out of foreign key relationships, mostly its not done because of performance. I do wonder if you built a database engine specifically around this paradigm if it would be fast enough.
But that doesn't have to be the case at all. It's common (in general, maybe not with customers and invoices) to store the relationship in a third table, say "customerinvoice", that has customerid and invoiceid fields.