notes from a passionate developer

Developer that lives by the mantra "code is meant to be shared".




This is a personal blog. The opinions expressed here represent my own and not those of my employer, nor current or previous. All content is published "as is", without warranty of any kind and I don't take any responsibility and can't be liable for any claims, damages or other liabilities that might be caused by the content.

Don't force your data-persistence solution to fit every needs

Daniel WertheimDaniel Wertheim

The N+1 is evil. I want referential integrity. I want...

"Hold it right there Mr!" A document-oriented Db (DOD) is not an RDBMS! If you are having an N+1 scenario or feeling a pain with references, you should probably first have a look at your model and your chosen data-persistence solution (DPS). Is it perhaps so that you shouldn't be using a DOD for the scenario you are having issues with?

The DPS are designed for specific use-cases and it's likely so, that if you find your self in a somewhat complex domain; you should have more than one DPS, instead of forcing one to fit in every context.

Vendors can bring all kinds of help to the table, generating proxies around your POCOs and let the DPS: track changes, manage references and automatically pull stuff in from the DPS into cache; All kinds of magical stuff could be done by the DPS. But is this really the way to go for a DOD?

If you are experiencing e.g an N+1 scenario as a result of you iterating over a bunch of documents referencing other documents. Could it perhaps be so that you should instead have designed a specific document containing all data for that particular view? Sure, that would mean you would take parts of documents and duplicate the storage of it, but you will get a view representing a certain context. This would benefit read scenarios whilst you will get harder to administer the write scenarios, and if that gets a pain (a real pain), you should start thinking of using another DPS that fits your needs for that use-case.

Just some rambling, nothing scientific. Agree or don't agree.


Developer that lives by the mantra "code is meant to be shared".