this course how to create the same web applcation using node js mongo db and php mysql: www.udemy.com/course/node-js-mongodb-vs-php-mysql-build-the-same-web-application/
I dont think I will ever be grateful enough for Maximilian. This man single-handedly taught me everything from HTML, CSS and basic JavaScript, all the way to Vue and React, Node.js, databases and REST API. Thanks to you I got a highly paying job, and can make anything that comes to my mind. Thank you sir from the bottom of my heart. :)
A key concept in this comparative analysis is consistency of information. - SQL (Relational Databases): a good design (scheme and constraints defined correctly and transactions are used properly) allows the database engine to guarantee consistency based on that design. - NoSQL: lower consistency of information (it is a responsibility of the developer to ensure consistency... some time this could be very difficult).
Man you knowledge base is beyond human scope...really. When i first started learning programming there where many times i coulnd't get you, after learning programming there a lot of times i realize how many miles ahead you are. RESPECT.
I really like this video with one singular exception. When discussing relational databases at 1:48 minutes into this video the narrator says: "The database we typically use is a relational database that means we have a database which works with certain assumptions". No other mention or explanation is given for this. Also there is never a mention of NoSQL databases working "with certain assumptions". I've designed/modeled and built relational databases for 19 years. I base every relational database design on one thing: Rigorous due diligence in requirements discovery and analysis. This means: 1) Requirements 2) All the requirements 3) Nothing but the requirements The one thing I NEVER base my relational designs on is "assumptions". No good relational database design should ever be based on assumptions.
The assumptions being made are within the database architecture. Such as assuming every user has a product id(for building out keys and references) so when you act on those relations, SQL engine expects corresponding data in other table(foreign keys as an example)
Thank you for this! I've been tasked to build a DB, but wasn't sure which type to go with. I tried using MongoDB and I can see where it has it's advantages. After watching this though, an SQL DB is better for our needs.
9:16 mongoDB may be the nosql with most tutorials, then again if you run postgres, mongodb and couchdb in strace, mongodb spends like 6 times the amount of resources to achieve the same performance compared to postgres or couchdb.
Another important thing to consider for SQL databases is the amount of time conceptualizing a SQL database takes. For an effective SQL db you need a proper ERR Diagram and schema that takes into consideration a ton of user interactions. One wrong step at the conceptualization phase and your whole relational system breaks. Similarly, the modification anomalies that may come from NoSQL can break your db, but to a more manageable extent IMO. When agile development reigns king, quick development with short conceptualizing phases means your better off with NoSQL despite the downside to writing-heavy applications. What do you all think?
13:00 you can save the user id in the user field of the orders collection, and when you query the orders collection, you populate the user field. this way the data does not get duplicated, it works just like a relation
Tremendous explanation. I have spent 3 days reading tons of information about differences between SQL and NoSQL, and have understood less than I expected, but this video made everything straightforward. Thanks to the author! Great work!
In terms of RDBMS a "relation" actually means a table (because it stores rows of "related data" - that is structured records vs just a bunch of values). What he calls "relations" are properly called "foreign key constraints".
Horizontal scaling (also called _scaling-out_ ) is challenging and can be inherently inefficient with a _shared-nothing_ SQL database like MySQL, as mentioned in the video. However, there *are* indeed _shared-storage_ SQL databases that are designed to dynamically scale-out (horizontal scale) seamlessly. This is accomplished by replicating the database _structure_ on each server node, but with virtual programmatic pointers in each table, rather than the actual rows (records) of data themselves. These pointers point to corresponding table structures on distributed Storage Area Networks (SANs) that contain the actual rows of table data. Given this complexity, an enterprise-grade dynamically scalable shared-storage SQL database solution like Oracle 18c is very expensive to acquire, implement, administer and support. During the mid-2000s, Larry Ellison used to love to brag about the horizontal scaling capability of Oracle's shared-storage SQL offerings verses IBM's DB2 shared-nothing SQL database.
Hi, thank you for putting the effort and time to explain in such understandable way the differences between SQL and NoSQL. I appreciate your effort ! Good Luck!
This is hands down the most concise and relatable explanation of a SQL-like database vs a NoSQL-like database I have ever seen. Random tips: -A good intro to SQL is reading Chapter 2 of the official PostgreSql manual. -As a frontend dev, it's easier to "pick up" NoSQL. Since NoSQL is literally a folder of JSON files that you can search(query) through. -But, it's easy to dig yourself into a hole if you duplicate your data in several locations and then need to update that same piece of data. -You can also hurt yourself when your not consistent with your property names. For example "first name" can be found as "f_name" or "firstName" in your NoSQL database -Just be careful, and very consistent when using NoSQL. For total beginners, I recommend to go with SQL and then migrate to NoSQL if needed. Think of SQL-databases as a really powerful sportbike motorcycle with really good training wheels. It's safe and you probably won't outride the bike.
We use an SQL database at work specifically PostgreSQL. Our "rules" for our schema all tables need a primary key as a sequence that is either called seq or id. If that tables p_key is not referenced in another table we call it seq if another table does use it, its called id so a user table would have a column id, then on the table referencing there would be a sequence and a column called user_id. All of out many to many tables we call tablename_xref (xref for cross-reference) so just looking at the database it makes a ton of sense. we also add control columns on every table prefixed with ctl we have an insert user, insert time, update user, update time the times are stored as dttm (time with timezone). any anytime a user inserts data or updates data its reflected in the control columns.
Namig them seq or id doesn't make any sense. First, you're using two names for the same thing: object identification. Second, when your table has seq and you have a need in the future to reference it, you need to change the code and schema. Third, goes together with first, you're mixing the concerns by putting higher structure information into entities and this is bad because it introduces coupling.
It really does depend on your line of work as to which type of database to use. In my line of work, 95% of the time you would use a no-SQL type such as Elasticsearch. But, as he mentioned, something like an order database, you would be better off using either SQL or an hybrid approach.
There are special commands so called "choins" @8:31 :-) I really love this german accent! Thank you for this comparison, very interesting and complete.
And one more comment about scaling. Horizontal scaling is possible in SQL world. Many servers offers 'replication', MS SQL Server offers also linked servers and so on. MySQL offers Clusters. So saying that in sql world only vertical scaling is possible is not 100% correct. Performance of the queries can be improved by indexes but also sql servers optimizes queries to be the most efficient. Also mysql offers few engines, eg. myisam with very limited functionality but very fast, and innodb which can be very strict and safe, but reduces performance. Additional question is which kind of database will require more hardware resources sooner, sql keeping just one entity of the data, or nosql storing same data multiple times ? ;)
Massively Parallel Processing (MPP) databases too especially for OLAP/Data Warehousing use cases; Teradata, EMC/Greenplum, AWS RedShift, (the database formerly known as) Microsoft Parallel Data Warehouse, Exasol, and Oracle Exadata (at least to some extent with push down filter parallelism in the storage arrays).
hehe, good answer, but I think we are talking about different level ;) You mentioned about very advanced solutions, which are very expensive as well. That video, imho, was more for beginners than for senior database architects :) but, you are 100% right, we can also mention about IBM DB2 which is/was, I don't know if that db is still maintain or not, object oriented database, RDBMS of course.
I strongly agree with this. Horizontal scalling in SQL world is possible, and not too difficult to implement. This videos have said it, vertical scalling have limitations, so developer often use replication as a solution to boost performance. In some case horizontal scalling are cheaper than vertical scalling.
Horizontal scaling on a SQL database is also possible merely through switching databases or hardware. You can easily start off with housing it inside something like XML or dBase using ADO for a simply desktop or low-traffic web application. Then switch out the database to say MySQL. Then MS SQL Server. Then move it onto an 8 core monster with 64GB of RAM and RAID'd SSDs. All this before you need to look at clustering.
I tried to get into NoSQL and every time I did I basically ended up creating a system and imposing schemas and basically just making it a somewhat messy SQL style db.
Horizontally scaling SQL isn't very difficult but it requires a backend to do some extra work behind the scenes (which isn't terribly hard to program). Implemented properly and under certain conditions it can be slightly faster than NoSQL. You can use Schemas with NoSQL, see tools like Mongoose. Mongoose also makes relations very easy with the populate function. If the data isn't likely to change frequently it would still be better to just nest the data you need and update it as needed for speed though. So SQL horizontal scaling: possible but more difficult than NoSQL. NoSQL: Schema-optional with reverse-compatible changes via some well documented apis Aside from those excellent video
It's actually not about SQL vs NoSQL but relational vs non-relational. SQL databases come with a lot of constraint and behaviors (triggers) and if your data is highly relational, you will have an advantage using SQL databases maintaining your data structural integrity. On the other hand NoSQL databases are very restricted in relational integrity enforcement tools, but they are faster, easier to operate and learn and are very convenient for specific tasks. In general, use relational database if you're not sure which type of DB to go with. It might require some extra planning but won't lead you to data integrity issues and migration to NonSQL will be mush easier. At the point you face the need of sharding you will surely be well aware of what type of DB you need and how to shard your data well. So I'd not worry about scaling at this point.
NoSQL is just a serialized dictionary for lazy programmers that would rather write schema in code than come up with table structures and normalize them...
I stg i've been looking for a content explaining this subject everywhere and for some reason it was so hard to find your video, you just gave the most clear explanation about the topic ever, i can't believe im able to understand this now, thank you so much god bless !!!
Thanks for sharing a very elaborated comparison of SQL vs NoSQL. At 19:46 of the video you mention we can face issues if DB becomes really really big. I have a some questions here: 1- What are the issues and which DBMS is favored? 2- Can you give an idea in terms of Gigabytes or number of records where we start thinking its becoming really really big? 3- Which one is easier for writing code for CRUD ops ?
So the diff lies mainly in: SQL - normalization leads to better updation of data > but read becomes slower (joining multiple tables) > horizontal scaling issue NoSQL - less relations amongst the collections > one collection holding info about other object of other collection as well (post document containing user's id, name, pfp etc) > easy to Read > hard to Update because of data redundancy > good horizontal scaling (having less relations/dependency among collections)
"Which database is better? Which one should you use? " PostgreSQL. That has a JSONB type whic means you can store Json documents and query them, and it has all the required features of a database: transactions, replication etc. Plus it has a large number of free extensions that enable you to connect it to mysql or oracle or even an XML or CSV file as a data source. PostgreSQL exlipses the abilities of MySQL, really, and it's also free.
What would you say are the major advantages of PostreSQL over MariaDB/MySQL? I'm just starting researching about them and just comparing their DATE fields makes me believe PostreSQL is much better but I'd love it if you could share more info.
PostgreSQL is a RDBMS and as such does not scale horizontal. If you require the performance of 10,000 concurrent servers you need a solution which scales horizontally. PostgreSQL is a nice RDBMS solution, I am not knocking it.
Thank you , To make it short : if you want more data customization use sql , and if you will do an archive-ish data (read and write a lot with rare update )use no sql
Well, even for archive, who forbid to use a different field name, or attribute key name and doing so, as example, miss the criminal records of a multi-recidivist because these records were archived under another field name? What good is such an "archive" ?
Relations = Tables (Product Table) Relationship = Relationship (One to One) Relation != Relationship that's the db language as we learnt it from our teachers
This video disregards any and all relational theory. SQL is not the same language as Sequel. Both languages are interfaces to the database, not the thing itself. What do tables (correctly: relations) have to do with containers? Containers are like waste baskets. Tables are linked to each other through constraints, not "tables" through "relations". Rows or records are remnants from earlier database models, like Codasyl. We say tuples now. And I could only make it to 5:40. Better info here (I just googled this site): www.ntu.edu.sg/home/ehchua/programming/sql/Relational_Database_Design.html
Great video. One of the other key things SQL databases tend to have over NoSQ databases are transactions. i.e. ACID (Atomicity, Consistency, Isolation, Durability) support. But, there is an argument that, if you structure your NoSQL documents well, ACID is not needed
Great video. I would add that with federated tables, json queries and so on, SQL is quite capable of doing everything you mentioned in a noSQL setup, but the cost is overhead. Ive never seen an instance where I couldn't horizontally scale an SQL database. Can you provide any examples of this?
I like most of the description here since I was trying to better understand the NoSQL standpoint. However, I do want to point out that not all SQL implementations are limited on horizontal scaling. Oracle DB since 10g (and better since 11g) has the ability to RAC scale horizontally and keep the data synched between nodes (servers). You do have to properly design the data distribution for such a setup, but when properly designed there is little to no limitations on scale.
and talking the presentation of data and visualizing it (for us, developers), both nosql and sql data can be represented as tables with columns and rows, this makes it simpler for the eyes to see and read.
Maybe I'm wrong but I think few things needs to be clarified, or at least discussed ;) 1. In SQL world 'relation' it's a synonym of 'table', connection between tables is called 'relationship', so all 'relations' from the video are 'relationships'. 2. Typical sql server like mysql, mariadb or so does not allow many-to-many relationships; That one shown in 5:09 is not many-to-many, there are two relationships one-to-many. Some languages, eg. C# or Java, allows to manage many-to-many relationships, but there are not done on sql server side.
No. The two regular tables connected by a relationship table is a man-to-many rerlationship. You can have a group ordering a product or a bunch of products
That's a bit academic talking. Imho, for sql server there are two one-to-many relationships. In the same way you can say that mysql/mariadb can store xml or objects. Of course it can, if you serialize them into string. MySQL knows `text` type but it has nothing common with xml support. MS SQL Server or postgresql have support for xml. There is a special type for it. Another example, GIS coordinates. Postgresql has special types for it. In mariadb you can store those coordinates as well. Again, as serialized array or bunch of columns, but is it 'support' for GIS things in mariadb? imho, it's not. You can handle it from application, not db server.
Your ability to teach, explain things is absolutly awesome. Im watching a lot of diffrent famous IT youtubers but your content is gold and definitly the best. You probably created more IT devs than any university of the world ;)
@@thabo5799 MarkLogic has supported multi-document ACID transcations since version 1 (it is now at version 10), and this is indeed still very unusual in NoSQL databases
Yes To me single object transaction is simply no transaction.. it is just atomic document "save". Transaction is two or more changes they are either all done or nothing done.
Thanks for a great general comparison... I know this is old, but thought I'd mention one thing that I think is overlooked in this video although technically correct. Specifically regarding relations and schema consistency. While you are correct in saying that it is not directly supported in Mongo, this responsibility is instead handed over to the ORM layer. Typically, at least in Rails with Active Record, you add all the schema enforcements and relational requirements in that layer instead. By doing that you eliminate most of the downsides you mention regarding data consistency. One other key feature that I think should be mentioned too is that you can create much more advanced data structures in the documents themselves. This is a very simple example, but lets say you wanted to quickly wanted to know which users ordered a specific product. One way to solve that would be to have an array of user_ids on the product collection which essentially acts as a has_many relationship. When displaying products you could easily describe how many users bought this product and even show if friends of the user bought the product (provided you have a collection for that data too). Maybe a stupid example, but hopefully you get the idea. I would say that the biggest downside to using mongo is if you have a lot of requirements to run group by queries. Although it is possible in mongo with aggregations, it is not as straight forward. For me, unless I'm writing a banking application, I would select mongo for every web application I would build. :)
I can tell you as a data analyst not organizing your data should be a punishable crime. Websites gather lots of data which is important to the business it is supporting. Without proper organization there is no practical way to use the information in any databases you create as reliable business tools. I work very hard every day just gathering haphazardly stored data into hopefully meaningful reporting with mixed results. Please whatever data storage technology you choose please consider how that data can be retrieved and used to inform the underlying business. This should not be an afterthought but it almost always is.
Keep en mind there are appliances like: PDW, Exadata, Teradata that support horizontal scaling easily, also it is possible to scale in a smp db (cluster deployments)
how about comparison in terms of clarity, reliability, maintainability of code for the two types of db? (my gut says the flexibility of nosql implies more sophisticated/complex code implies reduced clarity, greater likelihood of bugs, etc .. but .. my gut is not a reliable source of info.)
I like the nosql example for orders. It shows how nosql can easily retain historical data. When a product is changed, then a customer who ordered in the past, didn't actually buy the updated product. The order still shows the product how it was at the time of ordering.
Well people, just don't be confused with this incorrect description of SQL horizontal scaling possibilities, it explained here completely wrong. SQL scaling very good and not hard at all last several years, just use correct DB for your purpose.
Indeed. And furthermore, the presenter forgot about VIEWS, in SQL, which can act like a collection (the data seems already merged, and it is quite fast since it is done through indexing) in addition to be eventually dynamic too (if a value change in a table implied by the view, refreshing the record will automatically update the view). I fail to see how a NoSQL approach can index your stuff. It looks to me like having to find "who" has the telephone number 123-4567 when all I have is a phone book on paper, where the phone numbers are listed in order of the owner (from A to Z). I would have to walk through all the entries, one by one?
sql:-uses for shemas having relations and distributed across multiple tables only possible for verical scaling limitations are high for read and write queries nosql:-uses for schema-less having no relations and typically merged/nested in a few collections possible for both horizontal and vertivcal scaling great performence for read and write quaries
Great video 👍 Could you maybe have a part 2 of this that provide practical examples, eg. Pointing out a few tech companies that are using different type of DBMS and how do they store or work with their current data. For a fresh graduate like me that do not have industry experience, it will give some insights when searching for job roles
Note 1. Relational databases are not about relations between tables. A table itself is a relation. 2. In a one-to-one relation you can use identical id-s for linked records (rows).
The burger builder course? I have to get around to that as well. The way packages change so much these days does this cause any issues. Im sure Max has this covered though.
I will remind you that a SQL database is a term, not just a language. A SQL database is a database engine created to perform queries from tables. Today we have: 1) Tables only. These tables can me hooked up from different engines. 2) Tables + the engine The engine itself must be ready for relational bindings between tables, and ready to perform queries from all the tables.
I am confused here. If you have 10 collections and if each of them you use user object and if you change only a first name or a profile picture or cover you will have to update in all other places. Seems horrible. Again for scaling when you have many servers you have to update same things in evreywhere. So the conclusion is If you need a e-commerce (little big and complex) or marketplace no sql is a terrible idea. if you need normal app where only data read is heavy then no sql. To get best from both of the world, use hybrid database such as Arongo DB that support graph db, key value pairs, documents objects.
You do not need to denormalize data when using NoSQL (document database in this case), it's only one of the ways. If you do, you gain some and you loose some - weigh what is more important. You can fully denormalize it. You can normalize the data and reference it using foreign keys, but you don't have joins as in SQL. There are ways to join data, but depends on the database. You can also make joins in your code. it's easy but can be slower. It may be more that enough what you need, so again, it depends on your use-case.
Also... sometimes you could struggle with the relational data model for an e-Commerce or Marketplace software and document or graph data model would be better suited and much easier to use. This can save you a lot of development time.
schema-less is best here, if the field is not there it is the same as null in the other world, but without a schema the database is easy to update when you get a new version of you program
When you start a project, just use the technology you know the best (SQL or NoSQL), it will save you some precious time. If you are successful enough to reach the limits, you will have the resources to migrate to a different system, may it be partially or completely.
Good video, but sounds like you are a pro NoSQL. However the disadvantages of SQL stated are not entirely true as scalable distributed framework becomes more developed. With the structure and reliability of MySQL and the high scalability of Hadoop and performance improvement offered by both worlds, what you get is a powerful Relational, very reliable, less messy database. NoSQL is great but I just hope the looseness doesn't over complicate an already complicated ecosystem. Some of the relatively poor designs of the Internet is still causing a lot of problem currently. Overall "All Models are wrong, but some are useful"
A nice solution is to have all writes go to a SQL database. Then have a CRON periodically export all changes to your NoSQL DB. All your reads come from NoSQL. Very fast for reading, if you have a lot of reads, but the downside is that your updates don't appear to take effect until the cron runs.
Really? I am DB noob so please explain me what if you have for example 15 000 000 new records created or updated per minute in SQL DB? How much it would cost to periodically (for example daily or monthly or hourly) export this to NoSQL DB (like mongoDB) as you suggest? I would like the task to finish within a cycle so stuff to export doesn't accumulate. What hardware solution you suggest or what service solution you suggest within service providers like AWS, Google, Microsoft etc. Of course cost and real service and hardware capabilities are important factor like in real life.
@@obvioustruth 15,000,000 new records per minute into a SQL database? I suppose a server solution could keep up, although SQLite would probably choke on that. But, if NoSQL is faster for writing, I think I would first write to the NoSQL and then at regular intervals, copy the data to a SQL database for storage. Synchronization is such a tricky problem though.
For one to one in for instance MySQL I tend to instead of the example given in the video have a user table with id and then have a table that is supposed to map to that have no id column but instead a user_id column that is unique. Then you ensure you only have one for the user and that this one can not belong to more than one user.
so like 90% of the time you wanna use SQL. really the only disadvantage i got from this video on SQL is the horizontal scaling. i'll check back when someone somewhere finds a way to steal the horizontal scaling from NoSQL. but for now i cant live without relationships(double meaning intended). which i thought most SQL databases solution would have by now. other NoSQL is not as interesting as machine learning when i was curious what that was.
Great comparison that gives a clear overview of the two databases structure. I don't see anyone mention it in the comments. You are kind of technically wrong about one to one relationship between two tables in a SQL database. (@6:13) In your example you can still have 2 user records pointing to the same contact data record. This can happen if someone updates the table in the database or if there is a bug in your application logic. What you should have for a true one to one relationship is having both tables having the same id, this means that the PK of contact data table is also the FK to the user table with has PK id as well. Another approach is to have a unique constraint on the column contact_data_id to ensure that you cannot have multiple contacts with the same value. In the 2 cases above you would receive an error from the database if you try to add or update a user record with a contact_data_id that is already in use.
There is inner-join,left-join,right-join concept for horizontal scaling right?. Usually it feels much better to divide a complex table in sql like,user table into user_credentials,user_profile_Info,user_gallery,user_blogs etc. and when needed you can merge them using joins to send only desired data to the software. In ms sql you can do coding in sql similar to c/c++ and create function which can be use to perform some logical operations on data of tables before they are finally sent to the software. I think nosql is for those who are not good with sql and need an alternative.
First, MongoDB != NoSQL. MongoDB falls under NoSQL term and it uses only one of the data models: document data model. There are other NoSQL database types using other data models (graph, key-value...). The point of NoSQL, as told in video, is not to embed different information into one document (denormalize). It's just one way to store the data. MongoDB has exactly the same relations as a SQL database - we can connect the entities using foreign keys using IDs(1:N, N:1, N:N). The difference is that the MongoDB itself doesn't help you with that as much as SQL DB does - there are no joins to get connected data in one big query. Although MongoDB supports relations using links and references to some extent, but I am not MongoDB expert so I can't say how they work. I already wrote a management software using one other document database and I normalized all of the data. The downside was that I had to join the data by myself in business logic and I had to query the DB many times to retrieve all the data I needed. Sounds complicated, but actually it wasn't. I used less time as I would with a SQL DB, especially where I didn't have to take care of the schema. Probably it's not as fast as using SQL joins (it's more than fast enough), but the BIG benefit of it was that I could more nicely separate the functionalities in my application and prevent it from becoming a big-ball-of-mud. Architecture is also much cleaner, it is easier to do unit-testing and easier to add new features later. The benefits overweight the downsides by a big factor :). So if you need relations, that's not even a reason to use the SQL DB. Try to look into graph databases. Graph data model separates the data in the entities even better than document or relational model, plus with graph connections, you can do joins like in a relational database. Concentrate more on a multi-model datbases where they merge graph and document model so you have all the benefits of a document database (collections and json documents (with support for embedded sub-documents)), plus the benefits of a graph database (connections and querying). Pure graph databases don't have the concepts of collections and they lack (I cannot say for all) the json document format.
Really thanks for sharing, now I finally understand the difference. Some hints: horizontal scaling for SQL is possible (at least for MySQL and Oracle), of course it's trickier than the vertical scaling. The use of the same colors for SQL/NoSQL and Horizontal/Vertical Scaling is a bit confusing.
this course how to create the same web applcation using node js mongo db and php mysql: www.udemy.com/course/node-js-mongodb-vs-php-mysql-build-the-same-web-application/
Definitely needed this! I've hear NoSQL was faster than SQL, so it seemed very attractive. But most of my projects rely on the integrity of the data shared across different Models. This video has persuaded me to stick with SQL lol. The fact that updating one NoSQL Collection has no affect on linked Collections is a big downside. Thanks 👌👌
The thing is: You need a place where your relation rules live. In a sql database this is (in my experience) both: There are some relations in the db but they get ignored more and more, because they are difficult to manage and so more and more of the rules just live in the (hopefully single!) backend that reads and writes from the db. In NoSql you just keep everything in the code. But yes: Mongo is not the solution to everything, you still need to make a good concept. But if you're not doing waterfall, your schema will definetly change over time and this is a lot easier with mongo.
Thank you! Helped me alot! I was struggling to decide which one I would use in my project because I don't knew these core differences and concepts. (I really enjoy and understand most of what you teach and that's the reason why I bought some of your courses, even that english it's not my first language)
Thanks a lot for your awesome feedback Bruno, happy to read that the video was helpful for you! Thanks a lot also for your support, great to have you on board here and on Udemy :)
You can sure use NoSQL for storing different kinds of data and use structured links to that data with using SQL. Or you can just add a text field to store json format inside the SQL database to make it act like NoSQL. I'd suggest using SQL with Text fields to store jason format data with many multiple and each different sub fields to access. It is just easier and you won't need two database installations taxing your hardware.
Each noSQL DB has a unique way of manipulating them. If you want to manually query data from MongoDB you're practically writing javascript. Like for example if you would write SELECT * FROM CAR WHERE MANUFACTURER = 'Audi'; That would be: db.car.find( { manufacturer: 'Audi' } ); Where db is your database (you may have multiple) car is the name of the collection, an the find function accepts a filter object.
But don't forget that they are just tools for different purposes. If you just want to store and sometimes open stuff, then noSQL is better. If you want to do complex calculations on the data, reporting. Then SQL is more capable. I think for a quick project (like a school project) noSQL is better because its more simple. If you already know SQL or has to do some really SQL specific stuff, then just do that. For a very large enterprise project the best is using different databases for each kind of load, hybrid stuff. Where you store the heavy, "non-interactive" stuff on a noSQL document store, like peoples data, contracts. and the "interactive" stuff which you make calculations to on an SQL one, like invoices, payrolls.
SQL databases is simpler to work with, but it does not mean its optimized for huge data storage and retrieval. The world's largest data stores (banks, hospitals etc) is stored in NoSQL databases. Also, NoSQL technology is nothing new, it was used before SQL databases were invented.
@@tno2007 Who are you kidding? The world’s largest data stores certainly don’t use NoSql, in fact it’s the opposite, it’s based on a very strict schema set up, virtually preventing any form of error data input. They certainly would not use NoSql and neither would it be recommended. Databases have been around since the 70’s, before computers made their way into the office, most large corporations still use Oracle.
in mongodb it's true that you don't have a schema for your database in the database itself, but you can have a schema on the server (ex: the api). what's the difference then? the only difference is that you moved the validation part from the database into the server. If you have the validation part on the server, you can be as much flexible as you like. in this case mongo is the winner here
Hi.. great video. When you mention the difficulty of horizontal scaling with SQL, I don't think that is very accurate. MS SQL server allows you to build SQL Farms and SQL Clusters. Point and click operations that can be done by following a guide from technet.
SELECT location FROM places WHERE name = Waldo Joking aside, here's a summary from a retail perspective: SQL: user/supply tables that are fluid. NOSQL: order/purchase data that are concrete history Your app pulls up the purchaser/supplier from SQL (change in addy, change of name, change in credit), and then the complete exchange history from NOSQL.
0:36 SQL
9:00 NoSQL
13:13 Differences
Thank you for this.
this course how to create the same web applcation using node js mongo db and php mysql:
www.udemy.com/course/node-js-mongodb-vs-php-mysql-build-the-same-web-application/
Not all heros wear capes!
U know this is the only useful🙂 comment in the whole comment section
Thanks bro!
I dont think I will ever be grateful enough for Maximilian. This man single-handedly taught me everything from HTML, CSS and basic JavaScript, all the way to Vue and React, Node.js, databases and REST API. Thanks to you I got a highly paying job, and can make anything that comes to my mind. Thank you sir from the bottom of my heart. :)
A key concept in this comparative analysis is consistency of information.
- SQL (Relational Databases): a good design (scheme and constraints defined correctly and transactions are used properly) allows the database engine to guarantee consistency based on that design.
- NoSQL: lower consistency of information (it is a responsibility of the developer to ensure consistency... some time this could be very difficult).
Yes that is key, and was not mentioned
Man you knowledge base is beyond human scope...really. When i first started learning programming there where many times i coulnd't get you, after learning programming there a lot of times i realize how many miles ahead you are. RESPECT.
God bless this "vs" videos they are so good.
I'm very happy to hear that, thank you so much!
I really like this video with one singular exception.
When discussing relational databases at 1:48 minutes into this video the narrator says: "The database we typically use is a relational database that means we have a database which works with certain assumptions".
No other mention or explanation is given for this.
Also there is never a mention of NoSQL databases working "with certain assumptions".
I've designed/modeled and built relational databases for 19 years.
I base every relational database design on one thing: Rigorous due diligence in requirements discovery and analysis.
This means:
1) Requirements
2) All the requirements
3) Nothing but the requirements
The one thing I NEVER base my relational designs on is "assumptions". No good relational database design should ever be based on assumptions.
The assumptions being made are within the database architecture. Such as assuming every user has a product id(for building out keys and references) so when you act on those relations, SQL engine expects corresponding data in other table(foreign keys as an example)
Thank you for this! I've been tasked to build a DB, but wasn't sure which type to go with. I tried using MongoDB and I can see where it has it's advantages. After watching this though, an SQL DB is better for our needs.
The rule is always, when in doubt go for SQL.
9:16 mongoDB may be the nosql with most tutorials, then again if you run postgres, mongodb and couchdb in strace, mongodb spends like 6 times the amount of resources to achieve the same performance compared to postgres or couchdb.
Another important thing to consider for SQL databases is the amount of time conceptualizing a SQL database takes. For an effective SQL db you need a proper ERR Diagram and schema that takes into consideration a ton of user interactions. One wrong step at the conceptualization phase and your whole relational system breaks. Similarly, the modification anomalies that may come from NoSQL can break your db, but to a more manageable extent IMO. When agile development reigns king, quick development with short conceptualizing phases means your better off with NoSQL despite the downside to writing-heavy applications. What do you all think?
13:00 you can save the user id in the user field of the orders collection, and when you query the orders collection, you populate the user field. this way the data does not get duplicated, it works just like a relation
Tremendous explanation. I have spent 3 days reading tons of information about differences between SQL and NoSQL, and have understood less than I expected, but this video made everything straightforward. Thanks to the author! Great work!
Happy to read that the video helped to make things clearer, thank you Akmal!
This is the most clear explanation of SQL and NoSQL on TH-cam.
In terms of RDBMS a "relation" actually means a table (because it stores rows of "related data" - that is structured records vs just a bunch of values). What he calls "relations" are properly called "foreign key constraints".
Thank you! I was just about to write it
Horizontal scaling (also called _scaling-out_ ) is challenging and can be inherently inefficient with a _shared-nothing_ SQL database like MySQL, as mentioned in the video. However, there *are* indeed _shared-storage_ SQL databases that are designed to dynamically scale-out (horizontal scale) seamlessly. This is accomplished by replicating the database _structure_ on each server node, but with virtual programmatic pointers in each table, rather than the actual rows (records) of data themselves. These pointers point to corresponding table structures on distributed Storage Area Networks (SANs) that contain the actual rows of table data. Given this complexity, an enterprise-grade dynamically scalable shared-storage SQL database solution like Oracle 18c is very expensive to acquire, implement, administer and support. During the mid-2000s, Larry Ellison used to love to brag about the horizontal scaling capability of Oracle's shared-storage SQL offerings verses IBM's DB2 shared-nothing SQL database.
I learned a lot from this video. I am now prepared for the conference call and will drop some wertical scaling on them.
Hi,
thank you for putting the effort and time to explain in such understandable way the differences between SQL and NoSQL. I appreciate your effort ! Good Luck!
This is hands down the most concise and relatable explanation of a SQL-like database vs a NoSQL-like database I have ever seen.
Random tips:
-A good intro to SQL is reading Chapter 2 of the official PostgreSql manual.
-As a frontend dev, it's easier to "pick up" NoSQL. Since NoSQL is literally a folder of JSON files that you can search(query) through.
-But, it's easy to dig yourself into a hole if you duplicate your data in several locations and then need to update that same piece of data.
-You can also hurt yourself when your not consistent with your property names. For example "first name" can be found as "f_name" or "firstName" in your NoSQL database
-Just be careful, and very consistent when using NoSQL.
For total beginners, I recommend to go with SQL and then migrate to NoSQL if needed.
Think of SQL-databases as a really powerful sportbike motorcycle with really good training wheels. It's safe and you probably won't outride the bike.
Thanks a lot for your wonderful feedback and for providing the additional resources, I really appreciate both :)
We use an SQL database at work specifically PostgreSQL. Our "rules" for our schema all tables need a primary key as a sequence that is either called seq or id. If that tables p_key is not referenced in another table we call it seq if another table does use it, its called id so a user table would have a column id, then on the table referencing there would be a sequence and a column called user_id.
All of out many to many tables we call tablename_xref (xref for cross-reference) so just looking at the database it makes a ton of sense. we also add control columns on every table prefixed with ctl we have an insert user, insert time, update user, update time the times are stored as dttm (time with timezone). any anytime a user inserts data or updates data its reflected in the control columns.
👍🏻
Namig them seq or id doesn't make any sense. First, you're using two names for the same thing: object identification. Second, when your table has seq and you have a need in the future to reference it, you need to change the code and schema. Third, goes together with first, you're mixing the concerns by putting higher structure information into entities and this is bad because it introduces coupling.
It really does depend on your line of work as to which type of database to use. In my line of work, 95% of the time you would use a no-SQL type such as Elasticsearch. But, as he mentioned, something like an order database, you would be better off using either SQL or an hybrid approach.
There are special commands so called "choins" @8:31 :-) I really love this german accent! Thank you for this comparison, very interesting and complete.
And one more comment about scaling.
Horizontal scaling is possible in SQL world. Many servers offers 'replication', MS SQL Server offers also linked servers and so on. MySQL offers Clusters.
So saying that in sql world only vertical scaling is possible is not 100% correct.
Performance of the queries can be improved by indexes but also sql servers optimizes queries to be the most efficient.
Also mysql offers few engines, eg. myisam with very limited functionality but very fast, and innodb which can be very strict and safe, but reduces performance.
Additional question is which kind of database will require more hardware resources sooner, sql keeping just one entity of the data, or nosql storing same data multiple times ? ;)
Massively Parallel Processing (MPP) databases too especially for OLAP/Data Warehousing use cases; Teradata, EMC/Greenplum, AWS RedShift, (the database formerly known as) Microsoft Parallel Data Warehouse, Exasol, and Oracle Exadata (at least to some extent with push down filter parallelism in the storage arrays).
hehe, good answer, but I think we are talking about different level ;) You mentioned about very advanced solutions, which are very expensive as well. That video, imho, was more for beginners than for senior database architects :) but, you are 100% right, we can also mention about IBM DB2 which is/was, I don't know if that db is still maintain or not, object oriented database, RDBMS of course.
I strongly agree with this. Horizontal scalling in SQL world is possible, and not too difficult to implement. This videos have said it, vertical scalling have limitations, so developer often use replication as a solution to boost performance. In some case horizontal scalling are cheaper than vertical scalling.
Horizontal scaling on a SQL database is also possible merely through switching databases or hardware. You can easily start off with housing it inside something like XML or dBase using ADO for a simply desktop or low-traffic web application. Then switch out the database to say MySQL. Then MS SQL Server. Then move it onto an 8 core monster with 64GB of RAM and RAID'd SSDs. All this before you need to look at clustering.
Bartłomiej Bąk yeah. I had just finished writing this guy is a fucking idiot.
I tried to get into NoSQL and every time I did I basically ended up creating a system and imposing schemas and basically just making it a somewhat messy SQL style db.
Horizontally scaling SQL isn't very difficult but it requires a backend to do some extra work behind the scenes (which isn't terribly hard to program). Implemented properly and under certain conditions it can be slightly faster than NoSQL.
You can use Schemas with NoSQL, see tools like Mongoose. Mongoose also makes relations very easy with the populate function. If the data isn't likely to change frequently it would still be better to just nest the data you need and update it as needed for speed though.
So
SQL horizontal scaling: possible but more difficult than NoSQL.
NoSQL: Schema-optional with reverse-compatible changes via some well documented apis
Aside from those excellent video
It's actually not about SQL vs NoSQL but relational vs non-relational. SQL databases come with a lot of constraint and behaviors (triggers) and if your data is highly relational, you will have an advantage using SQL databases maintaining your data structural integrity. On the other hand NoSQL databases are very restricted in relational integrity enforcement tools, but they are faster, easier to operate and learn and are very convenient for specific tasks.
In general, use relational database if you're not sure which type of DB to go with. It might require some extra planning but won't lead you to data integrity issues and migration to NonSQL will be mush easier.
At the point you face the need of sharding you will surely be well aware of what type of DB you need and how to shard your data well. So I'd not worry about scaling at this point.
NoSQL is just a serialized dictionary for lazy programmers that would rather write schema in code than come up with table structures and normalize them...
I stg i've been looking for a content explaining this subject everywhere and for some reason it was so hard to find your video, you just gave the most clear explanation about the topic ever, i can't believe im able to understand this now, thank you so much god bless !!!
It means "not only sql" (= noSql,)
but not NO sql at all
@-.- Cat or just Mongoose, if JavaScript.
dynamodb has some structure so its not only.
Thanks for sharing a very elaborated comparison of SQL vs NoSQL.
At 19:46 of the video you mention we can face issues if DB becomes really really big. I have a some questions here:
1- What are the issues and which DBMS is favored?
2- Can you give an idea in terms of Gigabytes or number of records where we start thinking its becoming really really big?
3- Which one is easier for writing code for CRUD ops ?
19:00 summary is pretty solid.
This is the best introduction to the difference between SQL v.s. NoSQL databases on TH-cam. No wonder why this video gets near 2M views.
Will this video get a sequel?😂
I see what you did there :D
web witticism development
where is the NUCLEAR BAN button here??
I will JOIN you there in that QUERY.
NoSequel :)
So the diff lies mainly in:
SQL - normalization leads to better updation of data > but read becomes slower (joining multiple tables) > horizontal scaling issue
NoSQL - less relations amongst the collections > one collection holding info about other object of other collection as well (post document containing user's id, name, pfp etc) > easy to Read > hard to Update because of data redundancy > good horizontal scaling (having less relations/dependency among collections)
"Which database is better? Which one should you use? "
PostgreSQL. That has a JSONB type whic means you can store Json documents and query them, and it has all the required features of a database: transactions, replication etc.
Plus it has a large number of free extensions that enable you to connect it to mysql or oracle or even an XML or CSV file as a data source.
PostgreSQL exlipses the abilities of MySQL, really, and it's also free.
What would you say are the major advantages of PostreSQL over MariaDB/MySQL? I'm just starting researching about them and just comparing their DATE fields makes me believe PostreSQL is much better but I'd love it if you could share more info.
@@bakatoroi postgresSQL supports recursive querys and nosql features.
PostgreSQL is a RDBMS and as such does not scale horizontal. If you require the performance of 10,000 concurrent servers you need a solution which scales horizontally. PostgreSQL is a nice RDBMS solution, I am not knocking it.
Thank you ,
To make it short : if you want more data customization use sql , and if you will do an archive-ish data (read and write a lot with rare update )use no sql
Well, even for archive, who forbid to use a different field name, or attribute key name and doing so, as example, miss the criminal records of a multi-recidivist because these records were archived under another field name? What good is such an "archive" ?
Brilliant explanation! I have a feeling that I can learn anything by watching your courses!
21:00 My personal preference is to combine the index of elasticsearch and postgres
Relations = Tables (Product Table)
Relationship = Relationship (One to One)
Relation != Relationship
that's the db language as we learnt it from our teachers
This video disregards any and all relational theory.
SQL is not the same language as Sequel.
Both languages are interfaces to the database, not the thing itself.
What do tables (correctly: relations) have to do with containers? Containers are like waste baskets.
Tables are linked to each other through constraints, not "tables" through "relations".
Rows or records are remnants from earlier database models, like Codasyl. We say tuples now.
And I could only make it to 5:40.
Better info here (I just googled this site):
www.ntu.edu.sg/home/ehchua/programming/sql/Relational_Database_Design.html
@theopeterbroers819 Totally agree. If the author wanted to simplify the material, it is better to don’t mention “hard” concepts at all.
Great video. One of the other key things SQL databases tend to have over NoSQ databases are transactions. i.e. ACID (Atomicity, Consistency, Isolation, Durability) support. But, there is an argument that, if you structure your NoSQL documents well, ACID is not needed
Great video. I would add that with federated tables, json queries and so on, SQL is quite capable of doing everything you mentioned in a noSQL setup, but the cost is overhead. Ive never seen an instance where I couldn't horizontally scale an SQL database. Can you provide any examples of this?
Greenplum DB
I like most of the description here since I was trying to better understand the NoSQL standpoint. However, I do want to point out that not all SQL implementations are limited on horizontal scaling. Oracle DB since 10g (and better since 11g) has the ability to RAC scale horizontally and keep the data synched between nodes (servers). You do have to properly design the data distribution for such a setup, but when properly designed there is little to no limitations on scale.
and talking the presentation of data and visualizing it (for us, developers), both nosql and sql data can be represented as tables with columns and rows, this makes it simpler for the eyes to see and read.
Maybe I'm wrong but I think few things needs to be clarified, or at least discussed ;)
1. In SQL world 'relation' it's a synonym of 'table', connection between tables is called 'relationship', so all 'relations' from the video are 'relationships'.
2. Typical sql server like mysql, mariadb or so does not allow many-to-many relationships;
That one shown in 5:09 is not many-to-many, there are two relationships one-to-many. Some languages, eg. C# or Java, allows to manage many-to-many relationships, but there are not done on sql server side.
No. The two regular tables connected by a relationship table is a man-to-many rerlationship. You can have a group ordering a product or a bunch of products
That's a bit academic talking. Imho, for sql server there are two one-to-many relationships. In the same way you can say that mysql/mariadb can store xml or objects. Of course it can, if you serialize them into string. MySQL knows `text` type but it has nothing common with xml support. MS SQL Server or postgresql have support for xml. There is a special type for it. Another example, GIS coordinates. Postgresql has special types for it. In mariadb you can store those coordinates as well. Again, as serialized array or bunch of columns, but is it 'support' for GIS things in mariadb? imho, it's not. You can handle it from application, not db server.
Your ability to teach, explain things is absolutly awesome. Im watching a lot of diffrent famous IT youtubers but your content is gold and definitly the best. You probably created more IT devs than any university of the world ;)
That's awesome to hear, really means a lot to me! Thank you so much! :)
A very important difference that is not mentioned in this video is transaction.
Mongo supports transactions from version 4.
@@KeyhanHadjari It does, but only for one object... still pretty bad.
exactly, very important, omited completely.
@@thabo5799 MarkLogic has supported multi-document ACID transcations since version 1 (it is now at version 10), and this is indeed still very unusual in NoSQL databases
Yes
To me single object transaction is simply no transaction.. it is just atomic document "save". Transaction is two or more changes they are either all done or nothing done.
This is one of the few "VS" questions that really is useful, it comes up all the time in job interviews.
Thank you for the great explanation! I've been looking up a lot of information about databases and this is by far the best and most helpful video!
More Mongo Db
th-cam.com/video/U2QUb0gDkKQ/w-d-xo.html
Years ago I took a course of ObjectStore, it's like NoSQL where you store objects like in memory but in a object database.
Thanks for a great general comparison... I know this is old, but thought I'd mention one thing that I think is overlooked in this video although technically correct. Specifically regarding relations and schema consistency. While you are correct in saying that it is not directly supported in Mongo, this responsibility is instead handed over to the ORM layer. Typically, at least in Rails with Active Record, you add all the schema enforcements and relational requirements in that layer instead. By doing that you eliminate most of the downsides you mention regarding data consistency.
One other key feature that I think should be mentioned too is that you can create much more advanced data structures in the documents themselves. This is a very simple example, but lets say you wanted to quickly wanted to know which users ordered a specific product. One way to solve that would be to have an array of user_ids on the product collection which essentially acts as a has_many relationship. When displaying products you could easily describe how many users bought this product and even show if friends of the user bought the product (provided you have a collection for that data too). Maybe a stupid example, but hopefully you get the idea.
I would say that the biggest downside to using mongo is if you have a lot of requirements to run group by queries. Although it is possible in mongo with aggregations, it is not as straight forward.
For me, unless I'm writing a banking application, I would select mongo for every web application I would build. :)
that is simple:
you write in sql then create an api that load from sql then write in Nosql
and finally only read from nosql
or on an excel then concatenate to write as a nosql
I can tell you as a data analyst not organizing your data should be a punishable crime. Websites gather lots of data which is important to the business it is supporting. Without proper organization there is no practical way to use the information in any databases you create as reliable business tools. I work very hard every day just gathering haphazardly stored data into hopefully meaningful reporting with mixed results. Please whatever data storage technology you choose please consider how that data can be retrieved and used to inform the underlying business. This should not be an afterthought but it almost always is.
As is often stated, the unwashed will accept "garbage in, gospel out". They expect the data expert to perform magic and miracles.
I can totally relate to your situation.
Good rule of thumb for coders - write your code as if the next person that has to support it is a homicidal maniac who knows where you live.
Keep en mind there are appliances like: PDW, Exadata, Teradata that support horizontal scaling easily, also it is possible to scale in a smp db (cluster deployments)
how about comparison in terms of clarity, reliability, maintainability of code for the two types of db? (my gut says the flexibility of nosql implies more sophisticated/complex code implies reduced clarity, greater likelihood of bugs, etc .. but .. my gut is not a reliable source of info.)
NoSQL sounds like a big unstructured Excel spreadsheet where anyone can dump anything into a new row, inserted anywhere.
I like the nosql example for orders. It shows how nosql can easily retain historical data. When a product is changed, then a customer who ordered in the past, didn't actually buy the updated product. The order still shows the product how it was at the time of ordering.
Well people, just don't be confused with this incorrect description of SQL horizontal scaling possibilities, it explained here completely wrong. SQL scaling very good and not hard at all last several years, just use correct DB for your purpose.
Indeed. And furthermore, the presenter forgot about VIEWS, in SQL, which can act like a collection (the data seems already merged, and it is quite fast since it is done through indexing) in addition to be eventually dynamic too (if a value change in a table implied by the view, refreshing the record will automatically update the view). I fail to see how a NoSQL approach can index your stuff. It looks to me like having to find "who" has the telephone number 123-4567 when all I have is a phone book on paper, where the phone numbers are listed in order of the owner (from A to Z). I would have to walk through all the entries, one by one?
If u want add column in Deb then have to stop ur process then only can add but this doesn't applicable for nosql
This doesn't relate to what I said above about scaling.
sql:-uses for shemas having relations and distributed across multiple tables only possible for verical scaling limitations are high for read and write queries nosql:-uses for schema-less having no relations and typically merged/nested in a few collections possible for both horizontal and vertivcal scaling great performence for read and write quaries
Wow, this is a great information. As a beginning SQL learner, I got a good chunk of knowledge from your video. Thank you!
That's really cool to read Petar, thank you very much for your great feedback!
in nosql you don't have to duplicate repeating datas every time. You can assign the reference of an repeatetive collection to a field.
Appreciate the breakdown!
7:30 technically, the one to one relationship is also a one to many, because a contact can be reused by multiple users
not with the same id
@@zyhon881 I guess not if you have a unique index, but that was never really indicated
just was wondering about this topic and bam!!! the notification, sql vs nosql..
.. thanx max
Guess that was kind of the right timing for you then, so cool to read that :)
@19:50 Would love it if you could give examples of when or what type of data should be in SQL & What other type of Data is for NoSQL...
You have explained it very nicely Max. Cheers!
That's really great to read Soubhik, thank you very much!
It's so unfair dislike/thumb-down this resourceful video. Its 2020 and its so valid..Thank you.
Great video 👍 Could you maybe have a part 2 of this that provide practical examples, eg. Pointing out a few tech companies that are using different type of DBMS and how do they store or work with their current data. For a fresh graduate like me that do not have industry experience, it will give some insights when searching for job roles
Note 1. Relational databases are not about relations between tables. A table itself is a relation.
2. In a one-to-one relation you can use identical id-s for linked records (rows).
Off topic: I did the Complete React Course from this amazing dude and its great!
Thank you for your support here and on Udemy Jefferson! It really makes me happy to read that you enjoyed the React course :)
The burger builder course? I have to get around to that as well. The way packages change so much these days does this cause any issues. Im sure Max has this covered though.
That course started off my coding career and got me lots of jobs
Thank you Academind!!!!!!!!
I will remind you that a SQL database is a term, not just a language. A SQL database is a database engine created to perform queries from tables. Today we have:
1) Tables only. These tables can me hooked up from different engines.
2) Tables + the engine
The engine itself must be ready for relational bindings between tables, and ready to perform queries from all the tables.
I am confused here. If you have 10 collections and if each of them you use user object and if you change only a first name or a profile picture or cover you will have to update in all other places. Seems horrible.
Again for scaling when you have many servers you have to update same things in evreywhere.
So the conclusion is
If you need a e-commerce (little big and complex) or marketplace no sql is a terrible idea. if you need normal app where only data read is heavy then no sql.
To get best from both of the world, use hybrid database such as Arongo DB that support graph db, key value pairs, documents objects.
You do not need to denormalize data when using NoSQL (document database in this case), it's only one of the ways. If you do, you gain some and you loose some - weigh what is more important. You can fully denormalize it. You can normalize the data and reference it using foreign keys, but you don't have joins as in SQL. There are ways to join data, but depends on the database. You can also make joins in your code. it's easy but can be slower. It may be more that enough what you need, so again, it depends on your use-case.
Also... sometimes you could struggle with the relational data model for an e-Commerce or Marketplace software and document or graph data model would be better suited and much easier to use. This can save you a lot of development time.
schema-less is best here, if the field is not there it is the same as null in the other world, but without a schema the database is easy to update when you get a new version of you program
When you start a project, just use the technology you know the best (SQL or NoSQL), it will save you some precious time. If you are successful enough to reach the limits, you will have the resources to migrate to a different system, may it be partially or completely.
that is terrible advice.
why?
This is my favourite comments!!
@@John_Fx how. Cause it makes sense
Lemme code a whole OS in Python, including the kernel...... crap it took me over 10k lines and now I have to rewrite this in C and C++....
I have learned more with this video than with my university teacher in 2 months of classes.
Happy to read that the video was even more helpful for you than university Jose :)
thank you man!!! You are the best in this theme!
Excellent video for people planning to move from SQL to No-SQL world. Concise and to-the-point comparison.
Thank you very much Prabal!
I struggled to learn database until this tutorial. Thanks alot.
I am glad that accidentally found your video on youtube. the best explanation sql vs no-sql i've ever seen.
Good video, but sounds like you are a pro NoSQL. However the disadvantages of SQL stated are not entirely true as scalable distributed framework becomes more developed. With the structure and reliability of MySQL and the high scalability of Hadoop and performance improvement offered by both worlds, what you get is a powerful Relational, very reliable, less messy database. NoSQL is great but I just hope the looseness doesn't over complicate an already complicated ecosystem. Some of the relatively poor designs of the Internet is still causing a lot of problem currently. Overall "All Models are wrong, but some are useful"
Agreed
For somebody who is "pro NoSQL" he sure made SQL sound like the clear winner for most things.
I have watched a BUNCH of videos on this subject and this was the best one by far. THANK YOU!
Thanks for this video Max!! Comparison slide was more helpful.
Thanks for your nice and helpful feedback!
A nice solution is to have all writes go to a SQL database. Then have a CRON periodically export all changes to your NoSQL DB. All your reads come from NoSQL. Very fast for reading, if you have a lot of reads, but the downside is that your updates don't appear to take effect until the cron runs.
Really? I am DB noob so please explain me what if you have for example 15 000 000 new records created or updated per minute in SQL DB? How much it would cost to periodically (for example daily or monthly or hourly) export this to NoSQL DB (like mongoDB) as you suggest? I would like the task to finish within a cycle so stuff to export doesn't accumulate. What hardware solution you suggest or what service solution you suggest within service providers like AWS, Google, Microsoft etc. Of course cost and real service and hardware capabilities are important factor like in real life.
@@obvioustruth 15,000,000 new records per minute into a SQL database? I suppose a server solution could keep up, although SQLite would probably choke on that. But, if NoSQL is faster for writing, I think I would first write to the NoSQL and then at regular intervals, copy the data to a SQL database for storage. Synchronization is such a tricky problem though.
amazing. I finally understand now.
For one to one in for instance MySQL I tend to instead of the example given in the video have a user table with id and then have a table that is supposed to map to that have no id column but instead a user_id column that is unique. Then you ensure you only have one for the user and that this one can not belong to more than one user.
so like 90% of the time you wanna use SQL. really the only disadvantage i got from this video on SQL is the horizontal scaling. i'll check back when someone somewhere finds a way to steal the horizontal scaling from NoSQL. but for now i cant live without relationships(double meaning intended). which i thought most SQL databases solution would have by now. other NoSQL is not as interesting as machine learning when i was curious what that was.
Great comparison that gives a clear overview of the two databases structure.
I don't see anyone mention it in the comments. You are kind of technically wrong about one to one relationship between two tables in a SQL database. (@6:13)
In your example you can still have 2 user records pointing to the same contact data record. This can happen if someone updates the table in the database or if there is a bug in your application logic.
What you should have for a true one to one relationship is having both tables having the same id, this means that the PK of contact data table is also the FK to the user table with has PK id as well.
Another approach is to have a unique constraint on the column contact_data_id to ensure that you cannot have multiple contacts with the same value.
In the 2 cases above you would receive an error from the database if you try to add or update a user record with a contact_data_id that is already in use.
Now do Graph databases like Neo4j or Multi-model databases like ArangoDB
There is inner-join,left-join,right-join concept for horizontal scaling right?. Usually it feels much better to divide a complex table in sql like,user table into user_credentials,user_profile_Info,user_gallery,user_blogs etc. and when needed you can merge them using joins to send only desired data to the software. In ms sql you can do coding in sql similar to c/c++ and create function which can be use to perform some logical operations on data of tables before they are finally sent to the software. I think nosql is for those who are not good with sql and need an alternative.
Database course plz
No concrete plans to create one at the moment, but this might of course change in the future :)
So a reason why mongodb is for large scale is because there is no limit because it can be split horizontally?
Such a good video, thanks man!
First, MongoDB != NoSQL. MongoDB falls under NoSQL term and it uses only one of the data models: document data model. There are other NoSQL database types using other data models (graph, key-value...).
The point of NoSQL, as told in video, is not to embed different information into one document (denormalize). It's just one way to store the data. MongoDB has exactly the same relations as a SQL database - we can connect the entities using foreign keys using IDs(1:N, N:1, N:N). The difference is that the MongoDB itself doesn't help you with that as much as SQL DB does - there are no joins to get connected data in one big query. Although MongoDB supports relations using links and references to some extent, but I am not MongoDB expert so I can't say how they work.
I already wrote a management software using one other document database and I normalized all of the data. The downside was that I had to join the data by myself in business logic and I had to query the DB many times to retrieve all the data I needed. Sounds complicated, but actually it wasn't. I used less time as I would with a SQL DB, especially where I didn't have to take care of the schema. Probably it's not as fast as using SQL joins (it's more than fast enough), but the BIG benefit of it was that I could more nicely separate the functionalities in my application and prevent it from becoming a big-ball-of-mud. Architecture is also much cleaner, it is easier to do unit-testing and easier to add new features later. The benefits overweight the downsides by a big factor :).
So if you need relations, that's not even a reason to use the SQL DB. Try to look into graph databases. Graph data model separates the data in the entities even better than document or relational model, plus with graph connections, you can do joins like in a relational database. Concentrate more on a multi-model datbases where they merge graph and document model so you have all the benefits of a document database (collections and json documents (with support for embedded sub-documents)), plus the benefits of a graph database (connections and querying). Pure graph databases don't have the concepts of collections and they lack (I cannot say for all) the json document format.
"First, MongoDB != NoSQL."
No fucking shit. He literally says that right at the beginning of the Mongodb section.
Don't be dense.
@@justsomeguy8385 No need to be a dick.
"Probably it's not as fast as using SQL joins (it's more than fast enough)," does this mean all that comment is just on your personal assumptions?
Really thanks for sharing, now I finally understand the difference. Some hints: horizontal scaling for SQL is possible (at least for MySQL and Oracle), of course it's trickier than the vertical scaling. The use of the same colors for SQL/NoSQL and Horizontal/Vertical Scaling is a bit confusing.
Yes and more limited. For example oracle RAC depend on shared storage in some cases. Mongo is designed for clustering.
Thank you very much Max for explaining deep topics in simple and easy way
this course how to create the same web applcation using node js mongo db and php mysql:
www.udemy.com/course/node-js-mongodb-vs-php-mysql-build-the-same-web-application/
Definitely needed this!
I've hear NoSQL was faster than SQL, so it seemed very attractive. But most of my projects rely on the integrity of the data shared across different Models.
This video has persuaded me to stick with SQL lol. The fact that updating one NoSQL Collection has no affect on linked Collections is a big downside.
Thanks 👌👌
The thing is: You need a place where your relation rules live. In a sql database this is (in my experience) both: There are some relations in the db but they get ignored more and more, because they are difficult to manage and so more and more of the rules just live in the (hopefully single!) backend that reads and writes from the db.
In NoSql you just keep everything in the code.
But yes: Mongo is not the solution to everything, you still need to make a good concept. But if you're not doing waterfall, your schema will definetly change over time and this is a lot easier with mongo.
Thank you! Helped me alot! I was struggling to decide which one I would use in my project because I don't knew these core differences and concepts.
(I really enjoy and understand most of what you teach and that's the reason why I bought some of your courses, even that english it's not my first language)
Thanks a lot for your awesome feedback Bruno, happy to read that the video was helpful for you! Thanks a lot also for your support, great to have you on board here and on Udemy :)
You can sure use NoSQL for storing different kinds of data and use structured links to that data with using SQL. Or you can just add a text field to store json format inside the SQL database to make it act like NoSQL. I'd suggest using SQL with Text fields to store jason format data with many multiple and each different sub fields to access. It is just easier and you won't need two database installations taxing your hardware.
So how do you query in no sql? Missing the comparison there
Each noSQL DB has a unique way of manipulating them. If you want to manually query data from MongoDB you're practically writing javascript. Like for example if you would write SELECT * FROM CAR WHERE MANUFACTURER = 'Audi'; That would be: db.car.find( { manufacturer: 'Audi' } ); Where db is your database (you may have multiple) car is the name of the collection, an the find function accepts a filter object.
Cool! Thanks. I kind prefer that one, i dont like sql very much :)
But don't forget that they are just tools for different purposes. If you just want to store and sometimes open stuff, then noSQL is better. If you want to do complex calculations on the data, reporting. Then SQL is more capable. I think for a quick project (like a school project) noSQL is better because its more simple. If you already know SQL or has to do some really SQL specific stuff, then just do that. For a very large enterprise project the best is using different databases for each kind of load, hybrid stuff. Where you store the heavy, "non-interactive" stuff on a noSQL document store, like peoples data, contracts. and the "interactive" stuff which you make calculations to on an SQL one, like invoices, payrolls.
SQL is very easy IF you get to use it a lot. Then you get it.
If all you need to do is read and few updates, then have SQL database that creates the "collections" you want.
There is a database which is horizontal scalable, this are the MPP databases, like Teradata.
You convinced me: I'm going to stick to SQL.
Why?
@@SkiNNyPoNNy Good reasons metioned here: www.wix.engineering/post/scaling-to-100m-mysql-is-a-better-nosql
SQL databases is simpler to work with, but it does not mean its optimized for huge data storage and retrieval. The world's largest data stores (banks, hospitals etc) is stored in NoSQL databases. Also, NoSQL technology is nothing new, it was used before SQL databases were invented.
@@tno2007 Who are you kidding? The world’s largest data stores certainly don’t use NoSql, in fact it’s the opposite, it’s based on a very strict schema set up, virtually preventing any form of error data input. They certainly would not use NoSql and neither would it be recommended. Databases have been around since the 70’s, before computers made their way into the office, most large corporations still use Oracle.
Yeah. You can always have a redis cache
in mongodb it's true that you don't have a schema for your database in the database itself, but you can have a schema on the server (ex: the api). what's the difference then? the only difference is that you moved the validation part from the database into the server. If you have the validation part on the server, you can be as much flexible as you like.
in this case mongo is the winner here
wow, this was an amazing tutorial. Thank you very much sir!
2 years later from this video update and its super nice to hear all this information!
Hi.. great video. When you mention the difficulty of horizontal scaling with SQL, I don't think that is very accurate. MS SQL server allows you to build SQL Farms and SQL Clusters. Point and click operations that can be done by following a guide from technet.
SELECT location FROM places WHERE name = Waldo
Joking aside, here's a summary from a retail perspective:
SQL: user/supply tables that are fluid.
NOSQL: order/purchase data that are concrete history
Your app pulls up the purchaser/supplier from SQL (change in addy, change of name, change in credit), and then the complete exchange history from NOSQL.
For complicated ERD, use SQL,
For a simple database, use NoSQL (Firebase, MongoDB, etc..)