Your explanation are nice If you show slides and image to explain it will be much better and much easier for beginners to relate things you say and understand better
Give taking your own notes a try! Serious, listen to a video more than once if needed, pause and take a short note. Much better understanding AND better glued in memory, than just "consuming"/watching someone's slides! 🖖🏻👍🏻☕
In fact the "relational" part of database does not refer to the relations between different tables, but to the relational model as laid out by E.F codd. In this model, tables are called Relations and rows are called tuples.
I'm sure E.F codd was a smart guy, but I think it's misleading to say that all tables should be called relations. SOME tables represent a set of relations while other tables represent a set of entities. I also don't like the tuple term. "Tuple" means a thousand different things now.
SQL can handle many connections (you made it sound like SQL can only manage a handful of connections). If there is an appearance of “slowness” it’s likely related to the isolation level \ locking, which can be managed with good database design (9/ 10 times perf issues are attributable to poor developer choices). The choice between the two systems should be about isolation level requirements , scale (data volume \ geo-distribution) and the actual data model being stored. If you’re dealing with high transaction financial data, your likely not gonna go no sql. Likewise, if your storing IOT data then no sql is going to be better. If you’re never going to shard your data, mongodb is not worth it as SQL will outperform it.
So to sum-up SQL - fast to read - you can count on constant a format NoSQL - fast to write - hard to update - better at handling lots of connections at the same time (why?) - better at scaling - good for unstructured data
Hey man, usually a fan of the videos but I feel like this one fell pretty short. Alot of surface explanation without any real world examples which I feel would help extremely
An example: Suppose you are storing customer shipping addresses. On a SQL database, you might have columns for house number, street, city, state, zip code; which works for US addresses, but not necessarily for addresses in other countries. On MongoDB, you could format their address differently depending on which country they are in. But the database would not check the address is in the correct format, it would accept anything, you would need to do your checks in the application logic.
This was helpful. It would be even more helpful if you provide brief reasons for each claim on why SQL or NoSQL is better. For example, why is it usually quick to write but harder to read from a NoSQL DB?
i think its because NoSQL you can just shove objects in the database because order doesnt matter since the processing is done upon queries, hence why its harder to read.
it's not entirely accurate either - it depends on the scenario - there are some query examples that have nosql being 100x faster at reading compared to a sql query that involves multiple joins compared to a nosql read where it's just pulling a full document based on id whether sql or nosql is better fully depends on use case
Was really stuck with what setup to choose for a new project. I use SQL at work and NoSQL for side projects and have always felt more comfortable with NoSQL. Your last point about choosing whatever you're most comfortable with really resonated with me, great video!
There are reasons why big companies use nosql for one thing and sql for another. Google Docs will probably use nosql to store your documents since most you do is write to it and only read the document once to start editing it. As a company its important because you can reduce costs since the performance is better but you also use less resources. Thats also why autoscaling is used to reduce useless resources.
4:54 Isn’t one of the benefits of a nosql database like mongodb is that you optimize for reads by having denormalized data at the cost of more costly writes?
A legit conclusion. Both technologies are proportionally good. The SQL allows vertical scaling, while NoSQL - horizontal scaling. The SQL simplifies the usage of MVC, MVVM, Object Validation and bindings, while the NoSQL simplifies the ability to make changes into projects (very useful for e-commerce dbs). The idea to use JSON data as TEXT in SQL is promising as something intermediate.
SQL: for times you need to read & write data NoSQL: for times you want to hoard json that you don’t want to bother parsing and you rarely need to look anything up.
Imo you missed the most important feature of sql databases, which is ACID transactions. That's the fundamental stone of pretty much every enterprise application
True, although the larger enterprises have been transitioning to microservices and cloud architectures. Due to the CAP theorem, these distributed solutions are ACID non-compliant*.
This actually really helped me understand both! Currently I’m learning MySQL with php and I may consider using react with it. I say MySQL I enjoy for your explanation of the great structure and columns and I care about readability. Though I may learn mongodb in larger scale applications in the future. Since mongodb sounds great for big projects
If you use it properly then there are zero joins in NoSQL database and reading is faster than SQL. Cost of 1 GB storage is super low. So you can repeat data without worry.
i think you are missing some key points. almost everyone is dealing with relational data (SQL). NoSQL takes the responsibility for data consistency away from the database, and puts it on all applications using the database, which is not ideal. i like most of your other videos
I've been dabbling in SQL a lot more lately. I'm actually considering building my newest project using it as the database. Most likely going to go with PostgreSQL. Thanks for the content Kyle. Much love my friend!
MySQL is great for correlational studies, especially for routine data. However, it takes time to organize the tables. No-SQL is great for chaotic and dynamic based data. Think of data tracking a bipolar person.
Towards the end are poor pieces of advice. For one the decision to use SQL should be based on the logic of a solution not on how comfortable a developer is with SQL.
you are awesome but there is one problem that you speak so fast could you please slow down your speaking speed for those who do not understand English very well like me thank you
bigger companies use tons of different database types for different purposes but imo if u learn how to optimize SQL databases really well then u can apply these concepts to the other types
MongoDB isn't a relational database management system. Saying MongoDB is better than any RDBMS without first specifying the data shows a real lack of knowledge. Key constraints don't exists in MongoDB. There are no referential integrity checks. We use MongoDB for blob storage and store the MongoDB keys in SQL Server. It's great for that but I would never outright replace a normalized SQL Server or a MySQL RDBMS instance with MongoDB. Maybe a lot of people see MongoDB as being better because they don't want to worry about optimizing indexes and execution plans, and they see the "read" performance gains...but that comes at a cost of data integrity. It's a schemaless structure which means consistency doesn't exist. It will eat anything you feed it which can be dangerous. Think about what happens over time as you add/remove properties from your JSON or add/remove reference data based on changing business rules. Think about what that conversion would look like in MongoDB compared to a RDBMS instance. I know I sound pretty critical of MongoDB but I don't mean to. We use it and it works well for our needs but it's not a replacement for RDBMS. More of a supplement. NoSQL shines in write-once-read-many scenarios.
My home automation (power usage, solar generation) is in MongoDB. First few years it was in SQL-Server, then switched to MongoDB. I'm storing about 130 samples per minute for the past 5 years, I aggregate the date / device into 1,15,30,60 min, 24, month, year. It's simply flawless.
Video title is click bait & I feel you didn’t explain WHY the different NoSQL exist. What issue are they each trying to solve (i.e. why would they out perform a solution implemented in SQL)? NoSQL is a collection of DB paradigms (key-value, docstore, search engine, graph, etc). It would have been good if you had explained the key points that differentiate each type… imho
I've always heard people hating on mongo, like theo, but I've never quite understood why? I like postgres and find it to be pretty good, but a lot of times it feels stricter and slower, in my experience. I'm far from a database expert, but I really find it odd that people are so obsessed with the "relational" model. As if you can't essentially use foreign keys or do joins in mongodb. You pretty much can, though they might go by different names, and I've heard many people point out how silly a JSON oriented database is, but I can't really see an argument for why excel spreadsheets are so much better. I don't see anything wrong with either approach, but I'm struggling to see a lot of advantages for using antiquated SQL dbses other than certain key performance metrics and data integrity. That being said, it's just weird because NOSQL gets a lot of hate, but I've yet to hear the legitimate criticisms of it. I mean, I'm sure there are some, but I don't really understand why people think that data can't have relationships in MongoDB. I mean, you could argue that the structure of SQL databases causes them to more often return the data that you are looking for, but it also creates a lot of complexity in rules, functions, schemas, writing, etc. On the flip side, with NOSQL it always seems like the structure of your queries is a lot more important than the structure of your data. The end result tends to be pretty similar, but the approach is quite different. Is this just the angry grumblings of devs that don't like to change their process for doing things or are there greater issues with MongoDB "underneath the hood" so to speak? I'd really like to know because on the surface most of these arguments seem kind of arbitrary unless you get into the details. Good video. I mostly agreed with the points. I could certainly see the devil being in the performance metrics, but it doesn't really seem to be in the capabilities.
Hello! Coming from NoSQL (Mongo) to SQL What I don't like with Mongo is that if you delete a document (A) in one model that references another document from another model (B), then B is not deleted, you need to handle this manually If I understand well, there is no such problem with SQL databases ?
It depends on DBA. Problem that you mentioned is called referential integrity. If you don't implement correct technique during the design you might get a situation when a row from table A is deleted and another row in table B still references deleted row in table A. Thus, you will end up with inconsistent or redundant data. SQL server for example uses a way to CASCADE the changes (either update or delete) by primary key, this way all the references to the deleted or update data will propagate through out the database :)
Everything I've been reading and watching has been saying an opposite conclusion, that nosql is better for reads while sql is better for writes. This is all confusing me, but what I got was nosql expects you to duplicate data wherever you need it. So when making requests, all the relevant data you need is right there and the database doesn't have to do any extra searching for it. Sql wants you to have data in one place, and just make references to it wherever you need. So if you ever want to update data, you just do it in that one place it's defined and it'll be accessible everywhere. That'd make sql way better for writing data (as you only have to do it in 1 place), and nosql way better for reading data (as all your relevant information is already together) Can someone correct if I'm wrong, but isn't this the exact opposite of what this video is saying?
I still do not understand why would I use noSQL when I could simulate it in mySQL by (for example) adding a text field that contains some json. Is ti much faster? Or is there something else I'm missing)
"To sql or not to sql, that is the question. Whether tis nobler in the mind to suffer the keys and joins of outragous databases, or to take arms against a sea of tables and by opposing end them."
Sure. The trick is getting hired without one. if you plan to work for yourself, this isn't an issue. If you're looking at a small company, it's less of an issue. They're more likely to see what you can do than focus on paper credentials. If you're looking to get into a large corporation, you're going to need a degree as the HR departments will ignore you. I had a boss a few years ago that never finished his degree as he got hired out of college for a hefty some of money back in the mid-90s. Fast forward and he's applying to work for a large company and had what interviewed with the PM and several of the architects. They all have him the green light. HR sees he didn't have a degree and blocks the hire as the company requires a degree for that position.
MongoDB has full ACID transactions across shards, also atomic transactions. Consistent across multiple DBs in a cluster by setting write concern to majority
