5.13 Technical Debt and Good Design

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