Time
7 hours 36 minutes
Difficulty
Beginner
CEU/CPE
3

Video Transcription

00:00
I welcome the module five sequel development. This is less than one skim a development were the first sub lesson one point to design patterns
00:09
in this lesson, we're gonna discuss the approach were run to take when developing the skimmer for our application.
00:15
Um, and the next lesson will actually go over the requirements for our applications so we can better define what models and relationships we use. But in this lesson, we're just going to discuss the approach we're going to take now. What is the design pattern? Design pattern is an approach to designing software or programming that follows a
00:34
said pattern.
00:36
And the one that we're going to be looking at is model view controller. In fact, we're more concerned with the model,
00:44
So this is gonna be even easier for us
00:47
because we're gonna be concerned with the model which is in the database. We're not really gonna be concerned with the view
00:52
or the controller,
00:54
so that would make it a little bit easier for us. So why aren't we concerned with this? Well, because this is actually
01:00
ah, part of full stack development. So we were doing full stack development. We would be concerned with every part of this idea,
01:08
but right now we are strictly focused on the database or sequel.
01:14
Now the view and the controller would typically exist an application code. So that would be the PHP frameworks, like Clarabell or
01:23
Ruby or SP dot net and various other languages. But when we're dealing with the database, we're gonna be pretty much focused just on the model.
01:33
Um, so we're gonna discuss the ideas around creating models and creating relationships between those models. So let's go ahead and take a look at that.
01:42
So what is a model? Well, it's it's basically a noun, so it's a person, place or thing.
01:49
So
01:51
and model is also a table in a database.
01:56
I'm going to quote that out so it doesn't turn
01:59
that color on me.
02:01
So, for example, we could have a model or table called persons,
02:08
and each record in that model would be a person. So and we could say that the attributes of that model, our name, age, address and social security number and those would be the columns in that table
02:22
and attributes are data that belongs to the model or qualities of the model.
02:29
So These are some examples off models or tables that we could have in our application. I've seen some of these models and other applications so we could have a note table.
02:38
It's common for applications to allow users to place notes on various models. That's why we have the type here that's actually part of a the an idea called polymorphic
02:47
relationship. So, for example, let's say you have a you want affiliate notes to persons and states.
02:55
So when the notes related to estate, you would just put the word state here for that column value.
03:00
And when it's person you just put a person for that type
03:04
went in that column when it's ah
03:07
for that model. Now, the reason you do that it's so that you don't have to have multiple note tables. For example, you would have ah person notes, table and estate notes stable. It could be, ah, more tables you get. Generally, the more complicated the application gets. So you try to, you know, keep it simple when you can. Another example of model might be states
03:27
we have, ah, you know, 50 states, United States. Maybe
03:30
you have a table that's called States and each record is a state, and you have there Bridget abbreviation, their capital city and their name for attributes. Now these attributes can vary wildly. One applications person model might be very different from another applications, and more or less comes down to what that application is trying to achieve
03:50
as its end goal.
03:52
What service it's trying to provide to the users
03:55
again after groups are data that belongs to the model or qualities of the model.
04:00
The ah,
04:02
A note on attributes. A common mistake for those new to database program is to turn attributes into their own tables and models. Now, what would an example of that be? Well,
04:15
let's say you have the person's table
04:17
and now you have this new requirement or this idea
04:21
that a person could be employed or unemployed.
04:26
Well, there's two ways to ah, handle that
04:29
or that I have seen people address that kind of situation, and one, we might be that you make an employed persons table and you make an unemployed person's table.
04:38
Now you have two models off persons with one
04:42
very small difference, and that is one represents employed persons and one represents unemployed persons now, instead of doing that,
04:49
much easier approach would be simply to add.
04:54
And some of you might be thinking, Well, yeah, of course. But you know, I've seen
04:57
I've seen folks do these kind of things
05:00
is at unemployed field
05:02
and just, you know, make it false or true
05:06
for the value. When you add a record, now we can look at this person and tell if he's employed. We didn't need to make another table like that.
05:15
You know, another ah area where you might see that kind of ideas transactions. Maybe you have direct payments and in direct payments or
05:23
direct revenue and indirect revenue. And instead of making each one its own table, making it an attribute for that model.
05:30
Uh, so what is the model? Well, if you look at one of the databases that we were using previously, let's look at the employees.
05:38
Employees is a model. Salaries is a model.
05:43
Titles is a model,
05:46
and if you can see the same approach, an axiomatic it too, which is a
05:50
A data, any RP database. So you have the account model, you have the address model.
05:58
You know you have the
06:00
a bunch of different models carry your model.
06:03
Now there's other tables, and they're the serve, different purposes. But you can see that they've used the idea of models in their design.
06:12
So that brings this lesson to a close. Just to recap, we're going to use a
06:16
simple derivative of the model view controller designed pattern. But we're not gonna worry about control or the view. We're just gonna worry about the model.
06:24
We're gonna use this idea of models to create
06:28
our skim A based on the requirements we get in the next lesson. And we're gonna identify
06:33
one models we need, what relationships between those models we need. And we're gonna create a nice schema that would power an application of the type that will be described the next lesson. Anyways, I hope you enjoy this lesson. And I look forward to working with you throughout this module. See you in the next one. Thank you. Bye.

Up Next

Introduction to SQL

This introductory SQL training teaches SQL core concepts that can be applied in professional environments. Once students complete this course, they will be able to query and interact with an SQL database, and know how to design database schemas.

Instructed By

Instructor Profile Image
Kitt Parker
Instructor