[imack]

Definitely agree. Getting Rails up and running on MongoDB is a lot faster than with ActiveRecord on top of some SQL. Especially when your data format is changing quickly, it's nice to just make a few changes in the model rather than having to track migrations.

[jasonkester]

You realize that this has nothing to do with sql/nosql and everything to do with your chosen framework, right? If, you used, say, a framework that autogenerated itself from your schema at build time, then changing the database would be as simple as changing the database, which is trivial.

I think a lot of our perceptions about technologies are influenced by the things that sit between us and those technologies. A lot of the talk about this particular issue has nothing to do with Relational databases or key/value stores.

[rhizome31]

Either I didn't get your point or you don't know what what Rails migrations are. Migrations are just a way to "change the database" in a repeatable way.

[jasonkester]

Right, but the grandparent's complaint was that you had to change your model, then write migrations to match.

In other frameworks, you use your tool of choice to change the database schema, then build the project and you're done. All the "model" stuff regenerates automatically. Thus, schema/model changes have no pain associated with them whatsoever, so there's no particular advantage to using nosql vs sql.

[rhizome31]

With Rails' ActiveRecord the model introspects the database schema at run time and figures out field changes automatically. What it doesn't figure out is relations and you still have to specify them in both the database schema and the model. Since you're mentioning project build, I suppose you're referring to Java or C# frameworks. Are those frameworks able to generate code for relations as well? (I suppose this requires following naming conventions or setting referential constraints)

[jasonkester]

Yeah, conventions cover pretty much every case you tend to come across. Got a column called CompanyID that has a foreign key constraint over to the Company table? Perhaps this is a relation... Nice of Rails to make it acceptable to simply ask you to name your stuff in a consistent way so that things just work.

The added bonus of a build step is that you don't need to keep regenerating the same classes and SQL code every page load, but it's not really any different from the programmer's standpoint.

[vdm]

For a domain model SQL DDL is not as declarative as ActiveRecord.