3 ms·

I think another benefit of NoSQL datastores is the ease of making changes on a live system. There's a great presentation[0] by Steve Huffman (in part) about how

by Zak 17y ago

I think another benefit of NoSQL datastores is the ease of making changes on a live system. There's a great presentation[0] by Steve Huffman (in part) about how reddit ended up using Postgres as a key-value store as much for ease of adding new features as performance. Go with what makes sense for your application and worry about scaling when you have users. [0] http://news.ycombinator.com/item?id=1330552 http://news.ycombinator.com/item?id=1330552

fauigerzigerk 17y ago
Not using a relational database alone doesn't make changes any easier. Often times the complexity is just moved on to a different place or time. Of course a completely generic data model makes it easier to make a particular modification on a live system, but it makes understanding the system and the consequences of that change harder. The question is really which parts of the entire system depend on particular invariants and constraints? Where are they checked and enforced? How are the rules represented? Moving lots of rules out of declarative and into procedural code won't make things simpler. I have experimented a lot of with all kinds of data representations, non-relational ones mostly, but I have to say, there are trade-offs that are rarely discussed in a NoSQL context. Probably because NoSQL was primarily the answer to "how do we do something incredibly simple on an incredibly huge scale?" Many years of doing data integration have convinced me of one thing. Closely linking application code to data makes things simpler in the beginning but it leads to a completely unmaintainable mess rather more quickly than people anticipate. Data and applications have a very different life-cycle. Data lives longer and there is rarely a 1:1 relationship between application and data. That's actually where the real impedance mismatch originates, and I'm afraid it will never go away or become much simpler.

by Zak 17y ago

fauigerzigerk 17y ago

Not using a relational database alone doesn't make changes any easier. Often times the complexity is just moved on to a different place or time. Of course a completely generic data model makes it easier to make a particular modification on a live system, but it makes understanding the system and the consequences of that change harder. The question is really which parts of the entire system depend on particular invariants and constraints? Where are they checked and enforced? How are the rules represented? Moving lots of rules out of declarative and into procedural code won't make things simpler. I have experimented a lot of with all kinds of data representations, non-relational ones mostly, but I have to say, there are trade-offs that are rarely discussed in a NoSQL context. Probably because NoSQL was primarily the answer to "how do we do something incredibly simple on an incredibly huge scale?" Many years of doing data integration have convinced me of one thing. Closely linking application code to data makes things simpler in the beginning but it leads to a completely unmaintainable mess rather more quickly than people anticipate. Data and applications have a very different life-cycle. Data lives longer and there is rarely a 1:1 relationship between application and data. That's actually where the real impedance mismatch originates, and I'm afraid it will never go away or become much simpler.