5.13 Technical Debt and Good Design
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
7 hours 36 minutes
I welcome back to Module five sequel development.
This is less than four
working in the database.
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
use the procedure and create a category on the fly
or use an old categories, depending on what parameters were you passed in.
Now, in this lesson, we're gonna just We're gonna discuss a concept very briefly known is technical debt.
is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution. Now,
instead of using a better approach that would take longer.
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
because the models are what are stored in the database,
and then we also used various constraints within their database which caused us to need to not only
think about how to apply the constraints would also be aware of them when testing.
For example, when we added an article to the articles table,
the author idea is one of the columns that needs to be provided
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.
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.
in a production environment, we know very well that if someone is
adding articles with users that does not exist, that's probably a problem.
So we insert those constraints to prevent that problem,
and that good design
helps iron out bugs much more quickly
down the road.
For example, if we know that we have apply these constraints to our database
and we see a problem in the application
and there's multiple layers to the application, we have the application code. We have the data base code and we're seeing duplicates
in the application
from the front end to the user is looking at.
And if within the database we know
that there are unique constraints in the database table,
we much more quickly become confident that the problem is in the application code
and not the data base layer.
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
via the foreign key constraints and unique constraints. Now the swell of that application,
the less time both tape. But as an application grows
and you have thousands of tables and you have
thousands of lines of application core that becomes much more costly.
So this is definitely something to consider when designing any kind of database or application.
It's a very good idea to adopt a good design pattern, one that you can get comfortable with and follow
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
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,
then they will immediately know a lot about your application coming through the door.
So it's definitely a good idea to start
following best practice using it a design pattern
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
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