News for hackers. Stuff that matters.
Re:How NoSQL forced the evolution of a scalable relational d... by _Codemonkeyism on Friday July 13, 2018 @09:52AM (#17522970)
Same here, using Mongo helped us a lot to iterate fast, JSON is much more agile than SQL.

We now migrate to PG using 'core' attributes in tables and 'flexible' attributes in JSONB to get the best of two worlds.

I agree to the API problem, JDBC and PG/SQL is not as nice as a interace compared to Mongo libs.

Re:How NoSQL forced the evolution of a scalable relational d... by sytse on Friday July 13, 2018 @10:05AM (#17523064)
When you say JSON is more agile is that because you don't need to write migrations? Do you use a framework that supports migrations like active record or south?
Re:How NoSQL forced the evolution of a scalable relational d... by _Codemonkeyism on Saturday July 14, 2018 @06:15AM (#17529689)
We do not use migrations with JSON.

Adding and removing happens on the application layer with using Option[_] monads in the data model. Add a field means add Option[_], removing a field means making e.g. String an Option[String] - or fill with default values on read. If we drop a field over time we ignore it during writes.

   case class Person(name:String)
adding a job field after some time becomes

   case class Person(name:String, job:Option[String])
and application code needs to deal with it.

Works for us, compared to my previous jobs where we used SQL and migrations.

Re:How NoSQL forced the evolution of a scalable relational d... by collyw on Friday July 13, 2018 @06:02PM (#17527207)
Writing a load of consistency checks in the application layer sounds the opposite of agile to me. Unless you just want sloppy data.