6 ms·
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
by donpark 15y ago
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.
- imack 15y agoDefinitely 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 15y agoYou 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 15y agoEither 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 15y agoRight, 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 15y agoWith 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 15y agoYeah, 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 15y agoFor a domain model SQL DDL is not as declarative as ActiveRecord.
- Detrus 15y agoYea 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 http://redis.io/topics/twitter-clone MySQL will require the most boilerplate here, setting up schemas etc.