@sndselecta

The example at the end for me was a great explanation. Finally understand a simplistic implication. To further on this: a user is logged in, the cart is all products being purchased or a favourites section ,which will all be persisted to storage (HD). The transient (or constantly changing) data could be the session data (login duration day, week, month stats), product browsing history,  of that user, but wouldn't this be also stored at a later point? The cart and  favourites data is used by both user and supplier, but the session data is usually only used by supplier for analytics, targeted promotions, predictive data modelling (other product suggestions etc) etc...From the users POV might not be large but from a Product POV could be huge.

@carlosdegollado7687

WOAH! I've been thinking so hard trying to figure out which one I should implement when I completely forgot that there is the option of both....Thank you for helping me see that.

@Flankymanga

Each has its strengths and weaknesses and smart decision would be to employ both systems together with knowing where to store what....

@VivekYadav-vk2lh

I got lost in the thoughts about - how did you make this video ? how are you writing !!

@JanacMeena

SQL
- More pre-planning required
- Vertical scaling
- Better for multi-row transactions

NoSQL
- Horizontal scaling
- Unstructured

@jerrydeck7071

This is JEROME ROBINSON and I have to admit that  at first programing was so Confusing to me BUT NOW after practicing  it everyday I've developed a Love for it ! Programing i and Mathrmatics are so ENJOYABLE to me ( message from Jerome Robinson )

@jtaylor8606

This could have been easier to follow - in some parts you are using IT buzzwords to describe an IT buzzword concept - which is even more confusing.  It would be a lot simpler to understand if you could use plain English and examples - so, for example, what does horizontal and vertical scaling actually mean, what does 'dynamic' as point 4 on the No SQL side of your diagram actually mean.

In the first few sentences of the presentation you mention that it might be surprising that people ask questions about these differences between technologies, or that there is confusion about the differences, but in my mind it's not surprising at all when the meaning of the buzzwords/language used to actually explain the differences are unclear.

@prashantkumar6342

I appreciate your writing skills more

@chillbro2275

Wow interesting last point! I remember facing dev situations and feeling like a limitation of some sort, but perhaps taking a NoSQL approach would have lifted that. Quite exciting. There's a couple of teasers in  here that i'd like more information on. Like what is vertical scaling, what is horizontal scaling? And what accessing NoSQL looks like? But i definitely feel certain of the mode of SQL and the mode of NoSQL enough to experiment with NoSQL.

@LoneLeagle

SQL requiring more memory & computing power is making me lean more toward NoSQL because that means hosting is cheaper for NoSQL apps.

@dovasd

Good effort, but needs some more depth. The way is explained, makes a classic Oracle DB qualifying as NoSQP DB :)

@dexterplameras3249

A lot of people think NOSQL is a new concept. NOSQL predates Relational Databases by decades (1960s) and was called Hierarchical Databases. When Edgar F. Codd invented Relational Databases (early 1970s), computers weren't powerful enough to support them and it wasn't until 1979 the Oracle truly commercialized Relational Databases. Just like today Relational Databases need more computing power than the simpler NOSQL Database. This is because the main drawcard of RDBMs needs it, "Data Relationships". Without the relationships that SQL provides, one has to write the joins into their own code whether it be Python, Ruby, C++ , Go etc or rely on the same or similar SQL syntax to do perform joins (Hadoop, Splunk come to mind). SQL reduced the proliferation of code needed to do joins. Imagine having downstream systems using multiple programming languages, each one having to munge their own joins. RDBMs also provide other things such as ACID, which ensures your data is in a consistent state even if there are conflicts. Frankly once the data is normalised it easier to work with SQL plus ORMs.

@ha9u63a7

I am curious about "Vertical vs. Horizontal Scaling"

1. Why can I not scale SQL Databases Horizontally? You could use sharding and read replicas improve scaling needs - sure, it requires work, but SQL is constantly improving - isn't that right?
2. What I can see is - you can easily make changes in NoSQL e.g. unstructured - which is quite costly in SQL

@eddebrock

The person who understands what he's saying already knows the answer to the question.

@fleacircus4408

The visual presentation of this video is superb, but it's really let down by the audio, there's a very slight reverb/echo effect that lands perfectly in the uncanny valley of normal speech.

@ndeedd

The way he wrote is even more impressive 😮

@hatimshahera7961

how do they write the things in front of them? It means they are writing the other way around right? or what? I have been trying to watch the tutorial but my head is stuck at that

@lawrencegatley6157

Thank you! this is the perfect video for explaining the difference to me

@RU-qv3jl

The problem I see with your explanation is that SQL is just a language. There are an ever increasing number of options to scale out RDBMS systems. Also it’s not like, for instance, Postgres is bad at handling JSON data with JSONB. There are some attributes that you are likely to always want to have, and some that may change per instance. So something like a table with a JSONB column is a nice approach. However, I wouldn’t go around installing Postgres on loads of mobile phones for kicks. It’s just not reasonable to use that amount of storage space.

Just a thought.

@JG-sg7yy

Love it but the sound on this one was not good. Needs to be louder.