3 ms·
I don't know what 'I need the data to be transactional' means. One way to get isolation is to put a transaction in one document. Often this is easier and more
by artsrc 16y ago
I don't know what 'I need the data to be transactional' means. One way to get isolation is to put a transaction in one document. Often this is easier and more flexible that trying to take the 'car to pieces' everytime your park it. It is also more efficient in network bandwidth.
Everyone wants their data to be correct for some definition of correct. Normalized data is incorrect if the expectation is that relationships are preserved as the author created them, rather than re-created as they would be given the current database state.
For example, say a financial transaction record has an account holder and their related address.
For a naive implementation, if the address on the record should stay as it was when the transaction was created then:
* The normalized implementation is wrong
* The de-normalized implementation is right
If the address should be resolved at query time:
* The normalized implementation is right
* The de-normalized implementation is wrong
A lot relational tools (Foreign Keys, Unique Keys) become more complex for temporal schemas, which address these kinds of issues.
- DougBTX 16y agoAlthough I understand your point, I think you're confusing things by saying that you will get different answers depending on the degree of of normalisation. Strictly speaking, if two databases differ only in their level of normalisation, then they will store the same information, just in different places. When you update the denormalised version, you will have to update the same values in multiple places. If you don't want to update that value everywhere, then what you have isn't denormalisation, it is actually a different data model, which stores different information. Since you wouldn't be able to get to the "normalised" version you describe without losing information, it is probably wrong to call it "denormalised" in the first place.