0

This is a very "noobish" question, but I'm working on a project with a document database and I think they are using it wrongly. Thus, I kinda want to confirm this, as I feel it is tainting my experience.

In a nutshell, they seem to have brought a relational mindset to a document paradigm. For example, instead of embedding a particular JSON object in another, they are pulling them together in the business layer via ids (smells very much like foreign keys to me).

Now, it's true that repetition of data is avoided here (hey, as a SQL guy, I'm all about 3rd normal form), but I thought that having the data in there as part of the bigger document was more important than avoiding repetition of data.

I get that there are probably trade-offs and it may not be wise to have huge objects that contain everything, but I was hoping for a bit of guidance as to what is the best way to do things in this space and whether this place (probably) has it it wrong. (NoSQL is challenging if the blind is leading the blind).

Thanks

Improve this question

1 Answer 1

Reset to default
1

NoSQL is generally designed to store a denormalized data object as a way to persist it and eliminate the need for JOINs as a way to optimize for read performance.

But that doesn't mean JOINs aren't allowed in a NoSQL context, just so much as persisting denormalized and duplicated data is allowed in a traditional relational database context. They're just generally not the primary design focus of each of those types of databases, respectively.

My guess is you're probably correct that there's more of a flawed mindset in how your partners are designing the project, since they're JOINing in the application layer, but it really depends on your use cases.

Shape of data manipulations should generally be done proactively and persisted in NoSQL databases when possible, as your thinking is, but it doesn't always have to be persisted ahead of time and operations (such as JOINs) that are traditional in a RDBMS aren't always bad in a NoSQL database either.

Improve this answer
2
  • @JD Thanks. I knew it would not be a cut and dried answer. As an example, we have pricing plan (like mobile plans). I tend to think that should be a child of the Account document. But they just store an id and stitch them together in the app layer. If done my way, sure, the data is repeats across accounts. But I kinda think it would be nice to have it just there and available. There's a lot more of that going on. Anyhow, thanks.
    – onefootswill
    Jul 30, 2022 at 4:44
  • @onefootswill No prob! "If done my way, sure, the data is repeats across accounts. But I kinda think it would be nice to have it just there and available." - Right this is generally the design for a NoSQL database, good thinking. But there are tradeoffs doing it this way. Performance is improved by eliminating the need to join (which is one benefit of NoSQL) but data repetition increases complexity for data management and accuracy, when a value changes and needs to be updated everywhere it's duplicated. But I'd argue if your partners' design is relational, why even use a NoSQL database then?
    – J.D.
    Jul 30, 2022 at 11:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.