How NoSQL forced the evolution of a scalable relational database

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?

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]