3 ms·

I've seen many systems that use relational databases be patched up with if (null)/then/else in the application where fields have been added and the change was n

• po 17y ago
  Sure... I've seen that a ton. I've had to resort to writing a bunch of code like that as well. As an example of what I mean, there are some places where you can simplify by knowing that a relationship is 1:1 instead of 1:n because based on the current schema it's impossible for it not to be 1:1. You don't need an if/then or any logic in your application when you access that field. This means if you want to make it 1:n you have to change the schema and deal with all of the code that will break due to that change. Once that is done, then your application can input lists of items into the storage. In the document oriented approach, is seems like you (or any code touching the document type) just start inputting lists. This makes changing the schema a non-issue. It is up to the code pulling data to always assume the data could be null, single or a list of items. In the couchDB model it seems the schema is implicitly defined by the behavior of the application. I don't really know what that means for the application. I'm sure the tradeoff is worth it in a lot of cases, I'm just saying that this is one of the parts where my imagination is failing me and the unknown-unknowns are great. It seems like here the skills of writing a great REST API are more relevant than traditional data modeling skills.