Link Details

... also no Primary and Foreign keys, ... you don't need that stuff with RoR. It just hampers your creativity as designer and your productivity as developer.

Rails doesn't stop you from using foreign keys, and it requires the use of primary keys.

In fairness it does have primary keys and while the core doesn't believe in foreign keys for god knows what reason, there is a plugin that you can add in that adds foreign key constraint (redhill on rails).

Also sexy migrations provides support for foreign keys. It's pretty easy to write your own migration helper method to create fks too.

In fairness, an auto-incremented id is not a primary key. Esp. it doesn't prevent duplicate records (records identical except for the id).

Neither does any other primary key prevent non key duplicate entries. If you have a database of people and use something like ssn, employee id or what have you as the key, there is no way to prevent the same person from being entered twice if they get a second id. I take your point and religiousness against multicolumn primary keys is not an "opinion" I share, but surrogate keys are not out of hand bad (assuming you know that's what your doing).

That's why you use ActiveRecord's validates_uniqueness_of, and a unique index in the database on the table's natural key (if there is one).

So ActiveRecord validates database integrity. Does that make sense to you?

Wow, flame on.

No, AR doesn't validate database integrity. But you can specify some basic domain-level validation in the model. I did mention that you should have a unique index on the natural key as well, didn't I?

Have you ever used Rails?

I wouldn't characterize dzonelurker's post as a flame like comment. There are enough in the rails community that would hold that position or wouldn't know the difference. I don't think that you can blame a framework for the shortcomings of some of its users, but the fact that its ignored by the framework core developers does leave Rails open to the criticism. I would be stunned if they weren't also engaging in standard database practices under the hood in their apps and where they didn't, I bet they'd have a reason but would have thought about it.

Anyone who cares about their applications will think seriously about referential/data integrity and I'm hard pressed to come up with a good reason where you shouldn't have it in the database. Having it in the framework too is great, it prevents messy database errors. The only case I can think of where you need to avoid it is in Rail's polymorpic associations. Perhaps there are others, but its good to be aware of the trade offs.

Not to mention that the more "junior" adopters might take its absence for gospel practice for every situation and blog to us that we don't get rails or it just doesn't matter.

How dare he take the name of Ruby on Rails in vain!

This will surely bring them out of the woodwork...

And this is news?
,

No, this is the opinion of David Van Couvering

I use rails for several projects, but he briings up legitimate concerns. There is a good comment on the site discussing them in relation to rails sweet spot (smaller scale apps where developer time is the major constrained resource).

,
,

This is exactly why we had to rewrite a large rails built CMS. Since rails isn't threadsafe it requires a mongrel or fcgi instance per upload. So say you have 50 people uploading, you need to have 51 mongrel instances for the site to *function*. Each mongrel instance grows from 60-70 megs up to 100-120 megs. You do the math. For the most part Rails is nice for small simple CRUD projects. As soon as you deviate from its sweet spot you will run into issues.

I'm not sure when you rewrote it, but there are facilities for passing then handling of uploads from rails. Many use MERB which is thread safe and is a nice little framework in its own right.