Hacker News Reader

Comment by donpark | Hacker News Reader

Wrong from point 1. I use MongoDB and Redis because first is easier to prototype with ad hoc and second offers unique features one has to remap manually if SQL is used. In short, NoSQL requires less investment than SQL for my use cases.

View on HN

Yea to a database newb MongoDB and even Redis look simpler to use than MySQL. I was judging from the basic setup, syntax, boilerplate, tutorials, etc. Mongo's syntax requires the smallest learning curve, it's the dot notation you're used to. But that's was a total n00b's perspective and I imagine people that don't dive too deep in MySQL feel similarly. Generally programmers are superficial and look for the easiest syntax.

For prototyping purposes I'd like to see a comparison of building a twitter clone in MySQL, MongoDB and there's already one in Redis http://redis.io/topics/twitter-clone MySQL will require the most boilerplate here, setting up schemas etc.

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.

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.

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.

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.

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)

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.

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

Reply on news.ycombinator.com