Slashdot Mirror

Those who support PostgreSQL argue that its standards support and ACID compliance outweighs MySQL's speed.

One expression I remember seeing on the topic went something like: "I can make it as fast as you want as long as it does not have to actually work". The conversation was about filesystems comparing (the non-complying) async-mode with the safer (but slower) alternatives, that actually stood by the promise of fsync(2).

And another, more modern idea (only about 10 years old) quote is "Object/Relational Mapping is the Vietnam of Computer Science". Which, for the purposes of TFA, may be interpreted as something like "who cares for ACID compliance — we can deal with occasional data-corruption and inconsistencies — just make it fast in the usual case".

I rather doubt, we'll settle the question in this discussion...

Interesting article )and yes, I read the article), but the point of the NoSQL movement isn't so much about SQL, or ACID, as much as it is about Schema.

Most applications today are written in object-oriented languges like Java, C#, Ruby, etc... and most common frameworks in these languages use object-relational models to essentially 'unpack' the object into a relational model, and then reconstitute the objects on demand. this post explains the kinds of problems better than most.

NoSchema is about storing data closer to the format we process it in today. Key-Value pairs. XML. Sets and Lists. Object-Oriented data structures. This is about abstractions that make developers more productive. It is a tool in a toolbox, and useful in some circumstance and not in others.

SQL databases do not have to be the 'one persistence data mechanism to rules them all'. We don't need one; we need many that solve differing classes of problems well.

If you do it properly will will get a nice set of multidimensional objects and fact/attribute tables which are orthogonal and lean. Easy to understand, search, join, build, compose, decompose, signal and track.

I'm led to believe it's not that easy, but I'd love to be shown wrong.

Also, SQL is a nightmare

I agree, and I think one of the interesting questions is why we don't have something better, or even just something else. There are probably millions of man-hours put into ORM or QBE layers, some with their own hacked-up query languages... that are eventually re-written as an SQL query. But as far as I know, despite the fact that we have open source databases, despite the fact that storage engines aren't married to queries... we don't have any other query languages directly supported by the database (unless, I don't know, is QUEL still supported by Postgres?).

Where's D? Why not have Prolog (or a tabled prolog if you're worried about unbounded queries)? Given the fecundity of the field with regards to all kinds of different programming languages, I don't understand why there seems to have to be One Query Language(TM).

All frameworks (versus normal libraries) are problematic to a certain point of view, but ORMs are far worse. To understand why, read this: http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

If you insist on using ORMs, I personally suggest using JPA which abstracts away the underlying implementation and then migrating from Hibernate to EclipseLink. The latter implementation is much more solid and has a much healthier community.

Hibernate's authors are notorious for being rude to their users and their code is notorious for the hard-to-debug exception messages they through. Just my 2 cents.

Yes and not. All the O/R mapping layers have known good things and drawbacks (The Vietnam of CS) but specifically Hibernate it is a very wide deployed technology and ergo, recommended to the OP. Sadly, their "official" documentation sucks (apparently most was written by the original head developer): in many instances the javadocs do not explain the exact or complete semantics (apparently they assume you will be checking their source code all time); the confusing issue of their "default and broken connection pool", etc. Anyway, despite parent comments, they let you run plain SQL querys if you want or need.

(Addendum)

Here are two more links with yet more evidence that O/R mappers are very far from problem-free:

http://blogs.tedneward.com/2006/06/26/The+Vietnam+ Of+Computer+Science.aspx

http://www.codinghorror.com/mtype/mt-comments-rena med.cgi?entry_id=621

Basically, these tools are becomming more complicated than the very database they are trying to hide/wrap! Keeping app developer's inside an OO view of things is becomming more important than developer productivity and simplicity. It smells of W-style "stay the cOOurse" zealotry.

Issue 8 of the ZeroC (creators of the Ice RPC protocol) linked to an active discussion in the rpc blogosphere on the legacy of CORBA, the fate of SOAP, and the age old problems of RPC:

* exhibit A: 11:40 Oct 3, 05: Mark Baker claims CORBA was a technical failure ( http://www.markbaker.ca/2002/09/Blog/2005/10/03#20 05-10-ws-corba )
* exhibit B: 15:38 Oct 3, 05: Steve Vinoski of Iona (leading CORBA vendor) begs to differ ( http://www.iona.com/blogs/vinoski/archives/000214. html ); a long discussion including Michi Henning from ZeroC ensues in the comments, including:

Even if I do define WSDL that is "loose" and makes lots of things optional, that typically doesn't help me. Loose coupling isn't of interest just for its own sake, but is of interest because people are looking for a way to solve the versioning problem: how can I evolve a distributed application over time without breaking everything that is deployed already, and without having to recompile and redeploy the universe? If I define WSDL that is "loose" to start with, so I get the loose coupling I so much need, by implication, I know in advance how the application will evolve: I put the "loose" bits in the WSDL definitions where I expect future variation in the data. But real life doesn't work that way. None of us is prescient and, as a rule, what makes the versioning problem so hard is that we *don't* know how an application will evolve in the future. In other words, people who say that I can solve the problem by writing "loose" WSDL are kidding themselves: the real world is not cooperative enough for this to work.

* Michi Henning

It's odd that CORBA should end up being sidelined by most of its original supporters, in favour of a supposedly simpler and cheaper system that ends up being frantically complicated (well over 100 related specifications, and counting) and far more expensive. But that's business for you!

* Tom Welsh

* exhibit C: 23:05 Oct 13, 05: Ted Neward discovers and enters the discussion ( http://blogs.tedneward.com/CommentView,guid,070274 e8-ccfd-4ebd-87b5-494564c39b77.aspx )

And here is another prediction: once people get over their current fixation with loose coupling, they will finally realize that, to get loose coupling, I don't need loose type systems that throw away compile-time type safety, and I don't need support at the protocol level at horrendous cost in performance. All I need is intelligent system design, a middleware that offers a workable implementation of multiple interfaces (check out Ice facets), and domain-specific standardization. With that, I get type safety, flexibility, and performance.

* Michi Henning

* exhibit D: 17:32 Oct 22, 05: Ken Horn comments on the issue ( http://kendes.blogspot.com/2005/10/loose-coupling- corba-vs-ws.html )

Links

* PEPt - An Architecture for Adaptable Remoting Systems ( http://haroldcarr.net/pept/ )
* YAML ( http://www.yaml.org/ )
* A Conversation with Roger Sessions and Terry Coatta ( http://www.acmqueue.com/m