The assumption with Rails is that you can divert requests within the community for design changes into plugin development. That’s mostly true, except that it effectively limits the size and extent of such changes. If you want to add brains to a database which is otherwise totally “normal” from Rails’ point of view, the question is whether the project is as huge and twisted as adding brains to the Frankenstein monster, or if it’s just a matter of writing some good plugins.

There’s no doubt that you will find a lot of younger Rails developer espousing good practices, and being very proud of it, without entirely understanding them. That’s actually a huge improvement from a few years ago, when the average developer disparaged or ignored good practices without understanding them. It’s true that the Rails community gets incredibly annoying sometimes, but it’s also true that Rails is a thing of beauty.

Yes there are alternatives like Java and .net, kind of like democrats and republicans. If Ruby users didn’t think there was anything else they would be – Java ROFs (Religious Old Farts) – instead of the affectionately named fanboys we have been coined – hey we didn’t start the name calling.

BTW composite PKs are a great theory but in implementation they are a continuous cause of heart burn and refactoring that will haunt you until the product is retired – regardless of the language you are using. If you haven’t learned this yet you have been fortunately enough not to have had to maintain hundreds of thousands of lines of code using schemas written by someone else in your career. That being said Dr Nic has provided a plug-in to provide to handle this in AR for legacy applications. There are also plug-ins to handle stored procs and foreign keys and other aspects that you mention – had you bothered to look inside the Ruby world instead reaching for your favorite hammer to make everything look like a nail.

Your right this article wasn’t written for you, take a couple of aspirin and get over it.

we are talking here about activerecord, and how its a crappy product which ignores basic tenets of relational theory; whose community, when presented with these notions, instead of taking on the challenge of improving the product, or ever spending *30 seconds* to look at *anything* which is not rails, defends its mediocre design with lame ideas like using triggers in place of foreign keys and proclaiming composite primary keys as a poor design idea. None of this has anything to do with “me”; we aren’t talking about “me” here. So thanks to your response I guess we’re also now talking about the phenomenon of wagon-circling, ad-hominem diversionary bullcrap that inevitably arises in any attempt to seriously question any aspect of rails.

please! WTF, SQLAlchemy and Pylons are better than Rails, which is only for people who haven’t realized the true power of the database. God, those head bangers. sorry, the world isn’t as smart as you Mike.

@jamie,

Yeah, it’s an opinion, i’m not disagreeing, but I also don’t think it matters. You can use Rails with a database that has stored procedures, foreign keys, triggers, different transaction isolation levels. It takes a little bit of work, but you can do it. As far as the “simple database approach”? It’s the right choice for some applications, maybe not the applications you or I work on, but let bygones be bygones

Also, you seem to be determined to attack programmers who are defending the hill they happen to be standing on. I’ve seen it work both ways, very dogmatic DBAs defending Stored procedures against anything even resembling an ORM, and java programmers running around saying things like, “The database should be dumb”. Both side of the debate are wrong, the right answer is invariably: “do whatever gets the job done with the people currently at hand”.

But, to actually take a stand, i’ll say this. Stored procedures, OLAP, what have you are great ideas if the application demands them, but more often than not a problem can be solved with the simplest of tools. The challenge is knowing when to abandon the idea of stupid databases, and I think this is the problem you’ve identified. Stupid databases make sense for the simplest of application, but programmers tend to be dogmatic, so you end up with a whole department of hypnotized agilists holding on to the idea even in the face of conflicting evidence.

the problem isn’t stupid databases per se. the problem is dogmatic adherence to anything not founded on real experience. There are parts of agile mumbo-jumbo that make some sense, but 9 times out of 10, some 20 year old reads some Agile manifesto book and suddenly thinks that they have the 20/20 vision of a 30 year industry veteran – “Oh, we don’t need triggers or views, blah blah blah….” Where the 30 year veteran would actually end up saying…”Hmmmm….as a general rule, Stored Procs are not the first choice, but when we need them, let’s not rule them out.”

but, for the record, Rails is great. I’m sorry, but it just is.

Either way, the layer (library or application server) handles data consistency for you, in the same way that stored procedures would. You do, however, get to write it in a real language, instead of some poorly designed stored procedure language. You don’t tie yourself to one database (or at least, not as strongly). This is especially an issue if you’re writing an application used in more than one place (I.E. a product you sell to customers, as opposed to a product used by a single organization). You can also higher more general-purpose software engineers, who tend to be cheaper, smarter, and easier to find than Oracle engineers.