Welcome everyone to this lecture, which is going to give an overview of databases.
Now, put simply, databases allow us to store information that we can use on our website.
And we should briefly cover how SQL based databases work so we can understand that Django models analogous
operations that interact with that database, and we'll be talking about those in the very next lecture.
Now, sequel databases are tabular, similar to a spreadsheet like Excel.
But students often ask us the question What about no SQL databases like MongoDB, where no SQL stands
for not only sequel?
Let's quickly explore the visual difference between SQL versus no sequel.
Sequel, as we mentioned, stores data in a tabular format, and this includes things like a column
name and then rose defined by some sort of index often called a primary key in the sequel syntax.
Now here we can see an ID column, a name column and a color column.
And then each row is an individual entry like John or Mary.
Not only SQL formatting, such as MongoDB stores the data and a key value pair format very similar to
a Python dictionary.
So we can see here that same information just in a NoSQL format where you have ID, the name and color.
Now, the next question we're often asked is, which is better NoSQL databases or school databases?
And the simple answer is one format is not better than another.
They're just different ways of storing data.
However, you should note that if you're working with Django and Django models, they're designed to
work really well with a tabular skill based format.
So that is what we're going to choose for this course.
That isn't to say that Django can't work with MongoDB or not only sequel formats.
In fact, there's plenty of libraries that you can easily install in order to connect Django models
to a not only sequel or a no sequel database.
However, right out of the box, Django works so well sequel that we would highly recommend that we
that you work with that first before moving on to no sequel.
If you feel the need to.
Now, keep in mind, for most applications, a sequel tabular database is going to be completely fine.
And again, if you're beginning of Django, you should try to stick to a sequel before making a jump
to no sequel.
And you should really carefully consider if no sequel actually provides a major advantage to your project.
You shouldn't just choose no sequel because you think it sounds cool.
It should be pretty necessary rather than just upgrading to a larger sequel database.
So then speaking of a sequel database and sequel engines, we have to actually choose the type of sequel
engine we're going to operate in and there's lots of options.
There's my sequel sequel, I PostgreSQL, my sequel and many more.
Jingo is actually pretty agnostic to most major sequel engines with the use of a single model system,
so switching to another single engine, it's really more a matter of updating settings about pie and
pointing it to your new SQL database rather than rewriting the actual Python Django code.
Pretty much what we discussed in this lecture concerning models and Django and actually writing that
Python code is going to work with any sequel database as a back end.
So you don't really need to learn anything different.
If you decide to use a different SQL engine, so then when it comes to the choice, we're going to end
up using SQL light because it's actually already included and installed along with Python.
Often, students who read up a little bit on school life will typically think of it as a smaller scale
SQL engine.
However, you should keep in mind that for many use cases, school actually performs just fine.
And in fact, you can check out their official documentation on this called SQL, like the force when
to use HTML.
And keep in mind, it's a great choice when you're starting out because it's already installed and included
if you already have Python.
There's nothing necessary to add on or install.
And you should also note that school light, while it's typically thought of as a smaller scale database,
it actually can't scale to quite a large database and from their official website, they say quote.
Generally speaking, any site that gets fewer than 100000 hits a day should work fine of school.
And keep in mind that 100000 hits a day figure is a conservative estimate, not some sort of hard.
Upper bound and scale has been demonstrated to work with up to 10 times that amount of traffic.
So that would be up to a million hits a day.
So since you're just learning off Django right now, it's probably unlikely that you're going to immediately
jump to some million a day website.
And if you're at that scale, you would probably end up hiring people to actually run the website for
you instead of being some sort of sole developer.
So we're going to say SQLite is going to be totally fine for our use case.
And even if our site ends up being a really big hit and gets 100000 hits a day, it should still work
fine if sequel like.
OK, so what we're going to do is continue to explore these concepts by discussing Django models.
And once you learn about the Django model system, you're going to begin to clearly see why a sequel
is probably the better choice in regards to starting out with Django, because many of the actions and
Python code with Django models are a one to one connection to something in a sequel database.
Let's explore that in the next lecture.