3 ms·

"if you need a change in your schema, it's dead simple to do--just start using the new schema if you don't care that the old documents don't have the new field,

by po 17y ago

"if you need a change in your schema, it's dead simple to do--just start using the new schema if you don't care that the old documents don't have the new field, you don't have to worry about them" For me the scary part is that I usually do care. How do you stop caring about this? Doesn't this mean your application code starts to get populated with if/then/else? Is there a best-practice for backfilling data when the (effective) schema changes?

papaf 17y ago
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 not important enough to justify a data migration. I wouldn't say this practice is OK just that it happens quite a bit in my experience. If I was using couchdb I would assume that all but the most fundamental fields were optional and have the application act accordingly.
- 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.
alexpopescu 17y ago
I totally agree. It sounds everyone is thinking that just because you can put anything inside your store that's also a good idea. And it definitely is not. I am trying to underline this quite often: http://nosql.mypopescu.com/post/507962068/the-role-of-data-modeling-with-key-value-stores http://nosql.mypopescu.com/post/507962068/the-role-of-data-m...

by po 17y ago

papaf 17y ago

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 not important enough to justify a data migration. I wouldn't say this practice is OK just that it happens quite a bit in my experience. If I was using couchdb I would assume that all but the most fundamental fields were optional and have the application act accordingly.

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.

alexpopescu 17y ago

I totally agree. It sounds everyone is thinking that just because you can put anything inside your store that's also a good idea. And it definitely is not. I am trying to underline this quite often: http://nosql.mypopescu.com/post/507962068/the-role-of-data-modeling-with-key-value-stores http://nosql.mypopescu.com/post/507962068/the-role-of-data-m...