Any NoSQL true believers out there?

This troll job by MongoDB made me wonder if anyone is really hardcore in favor of NoSQL for general use-cases.

Comments

[Katie]

That's absolutely preposterous.

Good, attention-getting marketing, though. Can't blame MongoDB.

But if you have a boss actually influenced by an ad like this, make sure they and you have both read Dan McCreary and Ann Kelly's Making Sense of NoSQL.

Each major flavor of non-relational database has something it's good at (and plain-old relational databases in turn have things they're good at). This book will explain why.

They basically break databases down into 5 major types in use today:

1. "Relational" (This is your classic FileMakerPro / Microsoft Acces / Oracle / SQL Server / MySQL / PostgreSQL database. The one you think of as a database. From a beginner's perspective, you can think of it as a bunch of Excel spreadsheets that cross-reference each other, and each record in a "spreadsheet" has a defined set of values you're allowed to fill in (think of the column headers.))
2. "Key-Value"
3. "Columnar" (A specialized form of key-value database. Be sure to learn how, plus why it's different enough to get its own name.)
4. "Document" (A specialized form of key-value database. Be sure to learn how, plus why it's different enough to get its own name.)
5. "Graph" (Some versions are a specialized form of key-value database. Be sure to learn how, plus why it's still different enough to get its own name.)

Interestingly, from what I hear at Salesforce talks, they present a user interface to their customers that, for all practical purposes, gives those customers a traditional "relational database," but on the back end, Salesforce has been migrating from storing what actually goes into those "databases" away from a relational database of their own and into a ... I think it was a columnar database, but I wouldn't swear to it.

[Rom]

Am using CouchDB for a project and, franquly, I like it. Have used MongoDB in the past too. But am a long time SQL user, but since I have worked with NoSQL and when I have the choice, I’ve ended up always choosing NoSQL.

[Salman Ahmed]

NoSQL definitely has its place if you need "web scale", I'm not sure mongodb is the right tool for that job though. Most people use redis/memcached for a quick lookup cache, but the data is usually always in a relational store as the source of truth.

Real web scale use cases usually will use cassandra or other big boy tools :)

I'm not too familiar with mongodb as i haven't used it in a long time but it seems like mongodb tries to replace mysql/postgresql.

The question is, do you start a project using nosql as your main datastore? Or do you go with something more traditional that has known scale-out options.

[Stanislav(Stas) Katkov]

I will just leave this here

[Michael Scott Hertzberg]

if we're talking non-relational vs relational, there is an obvious need for non-relational databases and endless use-cases. document databases, graph databases, key-value store databases. the key-value store database is invaluable :P

[Yaser Al-Najjar]

Here is where things go wrong:

dev.to/0xrumple/comment/5e8l

Consider the other scenarios as well: what if you have to look for a particular lesson? You'll end up having to scan all of them!

Looking them how? by title?

That's not our job, that's algolia's job ;)

I really think your use case gains nothing by using a NoSQL store

The most part I feel will get right, is the logical nesting of documents instead of m2m ugly relationships which have no actual benefit.

go huge on caching (set up a Redis cluster, maybe?).

We do caching as explained here:

dev.to/0xrumple/comment/5ebp

so I'm really, really skeptical of throwing away a relational model.

I'm posting this here to make sure we are taking the right decision :)

[Yaser Al-Najjar]

Do you implement GraphQL on the controller layer? or on top on HTTP REST APIs?

[Peter Harrison]

Controller. Used the standard Java API for GraphQL, but the schema is dynamically generated when the entities are changed. The schema is not fixed, rather it is defined in data.

[Yaser Al-Najjar]

Thanks Peter... I will come with couple of questions when we start implementing the system :D

[Yaser Al-Najjar]

The answer for EACH one of your questions is YES !

But, what's the problem with copying one module from a workshop into another since it happens rarely?

Modelling relational data without the referential integrity constraints inherent to SQL is just asking for trouble

But NO, the ACID philosophy turned out to not be not pretty much scalable comparing to the BASE (no black/white case, it always depends).

You mention the need to perform 3 subqueries

As far as I see, we will replace them with just one query: get document (track) by id.

For filtering and shaping the data, I liked the way GraphQL works, we might add that layer on top of the normal query / REST endpoint.

but are you familiar with how onerous and haphazard it is to query/manipulate subdocuments in Mongo?

I know the lookup in mongo is a hell of an operator. But, let's avoid not seeing the forest for the trees... after all, (mongo and nosql) is like (bitcoin and blockchain).

If mongo makes the use of nosql hard, then there is dynamodb or firebase ;)

[Peter Harrison]

My applications are more like spreadsheets in that the user defines the data structures and relationships. They do this at runtime and the data structures are stored as data, but used when data is submitted. We have introduced referential links between entities and it is possible to create views which traverse the references. We have implemented GraphQL to be able to get data, which is also able to traverse between documents using references.

In relation to maintaining referential integrity because there is no coupling to the domain there really is only one area of the code that needs to worry about this. We reap other benefits from this approach, including a elegant security model which means we have fine grained access controls over what fields and documents are visible to users based on an access control policy.

Trying to author your own aggregations is folly. In our application we have been able to do complex data transformations easily by having easy to configure transforms which generate the aggregations. Doing it by hand would be a living nightmare.

Is MongoDB the best solution for everything? Nah. For highly structured data like telco call records SQL is the way. For apps that are tightly coupled to the domain, which is typically how things have been done, is fine. But... and this is a big but... the way we tightly couple applications to the data model is making our applications less flexible than they need to be.

Schemaless systems are opening the door. Ten years ago I was where you are now; SQL was the light and the truth. Today my view is broader and I have been given good reason to question the accepted orthodoxy. That said we can't be blind to the downsides.

[edA‑qa mort‑ora‑y]

It's a great model for document-like structures. This includes actual documents, but things like user records as well. If your data has a lot of single-entity structure to it, then I think the noSQL type databases are a better fit.

They also make development easier as they aren't as rigid. Playing with the "schema" is easier.

For mass record-like data I'd still use a relational DB.

Ideally, a good DB-engine would just provide both types of data and stop pretending one is "better" than the other. It's like trying to argue that functional is better than imperative when both combined is preferred.