Time
7 hours 36 minutes
Difficulty
Beginner
CEU/CPE
3

Video Transcription

00:01
I welcome back to Module five sequel development.
00:04
This is less than four
00:06
working in the database.
00:08
We're at sub listen. 4.4 constraints in good design. The previous lesson. We use sequel statements and procedures. Insert data into the database that we were working on. We use procedures to more easily deal with foreign key constraints. For example, when we added a category to an article, we could
00:25
use the procedure and create a category on the fly
00:28
or use an old categories, depending on what parameters were you passed in.
00:33
Now, in this lesson, we're gonna just We're gonna discuss a concept very briefly known is technical debt.
00:39
Technical debt
00:40
is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution. Now,
00:47
instead of using a better approach that would take longer.
00:50
Now, how does that apply to our database? And what we looked at? What we used a simple derivative of the of a design pattern known as model view controller. We focus more on the models
01:03
because the models are what are stored in the database,
01:06
and then we also used various constraints within their database which caused us to need to not only
01:12
think about how to apply the constraints would also be aware of them when testing.
01:18
For example, when we added an article to the articles table,
01:22
the author idea is one of the columns that needs to be provided
01:25
and the value in the author I D needs to exist on the user table on the user's i D table, and the relationship will then be that that user was the author of that article.
01:37
Now that causes us to during testing, worry whether or not the user exists. And if we're focused simply on articles, that might be considered an unnecessary concern.
01:49
However,
01:51
in a production environment, we know very well that if someone is
01:55
adding articles with users that does not exist, that's probably a problem.
02:00
So we insert those constraints to prevent that problem,
02:02
and that good design
02:05
helps iron out bugs much more quickly
02:08
down the road.
02:09
For example, if we know that we have apply these constraints to our database
02:15
and we see a problem in the application
02:19
and there's multiple layers to the application, we have the application code. We have the data base code and we're seeing duplicates
02:27
in the application
02:29
from the front end to the user is looking at.
02:31
And if within the database we know
02:35
that there are unique constraints in the database table,
02:38
we much more quickly become confident that the problem is in the application code
02:43
and not the data base layer.
02:45
Now, if we don't know that and we're like, Well, I didn't put any constraints in the database. Perhaps somehow bad data got into the database. That becomes an extra concern that we have to iron out so well now need an application programmer to look at the application code and the database programmer to look at the data base code
03:01
via the foreign key constraints and unique constraints. Now the swell of that application,
03:07
the less time both tape. But as an application grows
03:09
and you have thousands of tables and you have
03:14
thousands of lines of application core that becomes much more costly.
03:16
So this is definitely something to consider when designing any kind of database or application.
03:23
It's a very good idea to adopt a good design pattern, one that you can get comfortable with and follow
03:29
followed best practices during that design because those best practices will pay out in the long run. If you use constraints Foreign keys, design patterns, you'll be much more able or much more easily able to predict
03:44
the designs that you've used in your own applications. When you come back to rework them, add features six months, a year or two later, you'll have much more easier time getting other programmers to work in your application. Because if the other program understands the design pattern that you use,
04:00
then they will immediately know a lot about your application coming through the door.
04:05
So it's definitely a good idea to start
04:09
following best practice using it a design pattern
04:13
and with that said, that completes this lesson. This lesson was just a quick overview of a concept known as technical debt and why it's a good idea to use constraints, even though they might seem like they're a little bit of a pain in the beginning
04:26
and why it's a good idea to follow best practices and use design patterns. Hope you enjoy this lesson, and I hope to see you in the next one. Thank you

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