And you can easily and incrementally evolve your data model in an object database too with the added benefit that the application is updated to match the new data model at the same time.
> SQL databases are absolutely beautiful and elegant when you think of them in terms of the codd relational model
And horrible and brittle in terms of the application model, which in 99% of cases is not relational.
"""And horrible and brittle in terms of the application model, which in 99% of cases is not relational."""
I refer you to Philip Greenspun's explanation of why object databases don't work -
"""After 10 years, the market for object database management systems is about $100 million a year, perhaps 1 percent the size of the relational database market. Why the fizzle? Object databases bring back some of the bad features of 1960s pre-relational database management systems. The programmer has to know a lot about the details of data storage. If you know the identities of the objects you're interested in, then the query is fast and simple. But it turns out that most database users don't care about object identities; they care about object attributes. Relational databases tend to be faster and better at coughing up aggregations based on attributes. The critical difference between RDBMS and ODBMS is the extent to which the programmer is constrained in interacting with the data. With an RDBMS the application program--written in a procedural language such as C, COBOL, Fortran, Perl, or Tcl--can have all kinds of catastrophic bugs. However, these bugs generally won't affect the information in the database because all communication with the RDBMS is constrained through SQL statements. With an ODBMS, the application program is directly writing slots in objects stored in the database. A bug in the application program may translate directly into corruption of the database, one of an organization's most valuable assets."""
Which boils down to "relational databases are easier for non programmers to use", but I'm a programmer, I don't care. OODB's allow me to write applications much faster, and bugs affect both kinds of databases equally. Data corruption happens just as much in relational databases. I've used both, various relational db's for more than 10 years. I'm well aware of their strengths and weaknesses. Given the choice, I'll take Gemstone over a relational DB every time.
Treating the data as if it's separate from the application just leads to a big ball of mud schema that many apps share and the whole mess becomes a big steaming pile of crap that no one wants to change for fear of breaking a bunch of applications. The temptation to share state through the database is too strong. By focusing on the program, OODB's push you towards having each app with it's own db and programs interacting with each other through services, a much better architecture that's much easier to evolve applications independently with.
Exporting data from the application to a relational database for reporting reasons is trivial for those times you need it. Greenspun is simply wrong, object databases do work, and they work well for their intended domain.
From your profile i can see that your a smalltalk fan. Well, Alan Kay was onced asked where he thought the future of programming languages lies and he replied something along the lines of knowledge representation/logic programming.
guess what - relational databases are based on the first order logic, which is the most common method for representing 'knowledge', look at prolog or opencyc.
When you write sql you're actually working in a very high level language, higher than python or ruby or the language du jour.
I doubt Philip Greenspun is wrong. He learned programming directly from people at the mit ai lab.
The future may very well lie there, the present most certainly does not. Above all else I'm pragmatic and no matter how pretty SQL might be for getting the data you want, even if I ignore that it isn't actually relational, it simply doesn't fit well with the rest of the environment necessary to put a working application in front of a user today.
While I admire Alan Kay greatly, he's always been a bit of a dreamer. Dreams don't pay my bills, but object databases most certainly make me more productive, make my apps better, and my job much more enjoyable; SQL however, despite the fact that I know it very well, is always an annoyance that makes any project take long and require much more code than would otherwise be necessary.
As for Greenspun, everyone, no matter how famous or who taught them, is wrong about many things. Look at this website, we're having this discussion on a very popular site which uses a home-brew object database precisely because for many such sites a relational database is simply unnecessary and massive overkill and would create as many problems as it would solve. Relational database have their place, but they are a massively overused and over-applied solution. No blog, small website, or small biz appliction needs a relational database, they'd all be much simpler and work just as well with an OODB and quite frankly be faster and cheaper to develop.
> SQL databases are absolutely beautiful and elegant when you think of them in terms of the codd relational model
And horrible and brittle in terms of the application model, which in 99% of cases is not relational.