Satya Nadella, Microsoft's CEO, discusses AI agents and quantum technology in an interview on the South Park Commons YouTube channel. At 29:36, he ...
For further actions, you may consider blocking this person and/or reporting abuse
MongoDB is amazing... until you go further and discover graph databases such as Neo4j, OrientDB, et al.
The one thing MongoDB seems to have forgotten about is relationships between entities, that can be themselves messy, hence the idea of using graphs to enjoy the goodness of traversal algorithms for DB searches.
What about a graph query language on top of MongoDB:
PuppyGraph - Querying MongoDB Atlas Data as a Graph
didn't know about that... however, it's still an adaptation, an afterthought. That means all graph-related stuff happens outside of the DB space, in library space, so it's going to sacrifice performance compared to native graph DBs
anyway, please don't get me wrong, I don't want to diminish MongoDB at all, it's an excellent product with its space in the market, still great at a number of things
No problem, and you are right that a purpose-built database should perform better for its use cases than a general purpose database. But I only rely on execution plans to understand the performance difference, and didn't test PuppyGraph on MongoDB yet - but that will come
Mongo is in no way "purpose-built" for persisting business entity data, and general purpose database engines have been optimized for over 50 years to quickly, efficiently, and reliably store and retrieve relational data. They also provide relational integrity, which typically must be coded and maintained manually in document databases like Mongo.
Please, please learn more about SQL databases, and stop these misinformed and misleading posts.
Never said that 🤷🏼♂️. MongoDB is a general purpose database.
I'm writing this because I know SQL databases. I'm a big fan and have worked 30 years with Dev and Ops on DB2, Oracle, PostgreSQL, and others. I don't know what makes you angry. I wrote this to provide an example behind "The World Is Too Messy for SQL to Work" for those who want to understand where it might come from.
There's no need to read it if you are convinced that all data processing must happen in the database, on a fully normalized data model with all integrity constraints and stored procedures. You are right. But some developers and architects might think differently, and it can be interesting to listen to them and try to understand.
I don't know why you think I'm angry. I'm very calmly stating that what you're telling people is wrong and calmly asking you to stop.
I've worked for 30 years cleaning up expensive messes caused by people who are convinced that they know what they're doing.
"All models are wrong, some are useful"
en.wikipedia.org/wiki/All_models_a...
SQL presents a relational data model. It can be useful, and has semantics that can be predicted, and enable powerful queries.
Documents, not so much.
Sure, use documents if you want flexibility -- just don't hope to get very efficient queries.
Why not efficient queries? You can do good and bad queries on all models. The document model gives more control to the application developer (which can be good or bad - depends on the developer 😁) rather than the database (How Good Are Query Optimizers, Really?).
An example where storing as a document helps to index more efficiently: dev.to/franckpachot/a-case-where-s...
Sorry, but this is complete nonsense.
SQL does not in any way serve as "an API for relational databases". Structured Query Language (SQL) is a domain-specific language (DSL) that is used to manage data in relational database management systems (RDBMS). It excels at set-based operations and is no way an Application Programming Interface (API).
What your examples establish is not that the world is too mess for SQL but that your (and possibly Mr. Nadella's) understanding of and approach to data modeling (not to mention business processes) may be a bit too simplistic.
For example, there is no need to associate a single city and country with a single airport, and international airports are hardly the only examples where trying to do so will probably introduce problems. Relational databases easily support many-to-many relationships where multiple locations can be associated with a single airport, etc.
There are also issues with the assumptions you've made in your quick and dirty data model that will come back to haunt you, but the bottom line is that using a document database for business entity data is simply wrong -- the wrong tool for the job.
I could go on and on, but my How Bad Things Happen … in the Data Layer article on Medium covers most of them.
Please learn more about SQL and how to use it correctly and well before pronouncing it insufficient. Many, many relational systems disprove your thesis statement all day, every day.
I know what SQL is, and how it was designed to process data in databases. But some developers and architects have reasons to run some data processing in the application tier, then use SQL as an API to the database service. Wasn't called API in 1992, because two and three tier architecture were not out in the wild, but look at the four "Classes of SQL-statements" in the SQL standard, and you will recognize API.
Yes, but that's exactly the point of the example: normalization forces you to make a Many-to-Many the general case when it is the exception. Yes, of course relational databases support it, but with more complexity, harder query planning, and less declarative integrity constraints (in the absence of assertions define in SQL but implemented in no RDBMS). And getting back to the API: how do you return a Many-to-Many with one SQL statement when the result set is a single two-dimension table?
If you don't need it and don't want to learn it, then, sure, it's wrong for you, don't use it. But some developers are more successful with it. No reason to be angry, different development approach, skills, architecture decisions, requirements. I like to listen to others point of view. I could have stayed working on SQL databases for life, but I like to listen to developers and share what I learn from them.
Not if you think SQL is an API, regardless of where it's run. APIs are collections of discreet endpoints.
They are interfaces, as the name states, not a language, which SQL is. One cannot, for example, combine or nest API endpoint calls, e.g.
GET http://myapp/airports/(GET http://myapp/cities/1), as you can with SQL sub-selects, etc.Even more nonsensical. The thing being modeled determines the appropriate approach. Some things are by their nature one-to-many; other things are many-to-many. You've done it correctly if your model accurately reflects reality.
You're joking, right? Off the top of my head, something like this:
No, it's simply the wrong tool for the job. I'm not saying you can't get it to work, but you'll spend more time and money than necessary (and needlessly complicate the tech stack) getting it to work reliably and correctly.
Each correctly-modeled business entity -- a representation of the person, place, and thing (or "noun") our systems are intended to manage -- is by its nature a consistent set of attributes that does not often change. This is ideal for normalized, highly structured, relational tables. Document databases are ideal for semi-structured data that can vary widely from instance to instance.
I use NoSQL databases where they are appropriate. They are not appropriate for entity data.
Please stop sharing what you've learned from listening to developers. It's incorrect on several counts.
The best is to have the best of all worlds. Oracle converged database with json-relational duality, graph support, relational, sql and hey, even support for MongoDB wire protocol :) Oh, and vector support
Yes, sure, people who want to escape Oracle Database don't do it for the lack of features.