Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

9 hours 41 minutes
Video Transcription
I welcome back to Model seven. This is less a 7.4 triggers and this lesson. We're going to review and implement triggers in our database now for review. Triggers respond to indicated changes in the data base so they could run before update after update after delete before insert and so on.
They do not support transactions, and you typically do not want to use triggers for critical database update. For example, inserting customer payment records or updating customer payment records their best used for logging or enforcing unique business rules, such as rounding to a required precision.
Now triggers Do get a bad rap in the industry due to a lot of poor implementations. If you program a trigger well, it will work well for you now something they could make triggers. Difficult to work with is if they are not properly documented or they're coated in a confusing manner,
and also bad performance can occur. If they're not written efficiently,
for example, consider it in after update trigger. Let's say you have a somewhat expensive trigger that occurs after an update. Now for a single record, maybe it takes two seconds to run, and that's not a big deal. A customer might update the record and they wait two seconds and
they can. They don't notice it and they move on.
Now let's say that there's some process in the database that updates I 1000 records now 1000 times to would be 2000 seconds, which will be a long time to wait. And that could definitely stop someone from doing their job or bring the application to a halt.
So that's the kind of things you want to be careful about
when writing triggers now. With that said, let's go ahead and move over to the development environment and take a look at implementing it. Trigger.
I welcome back to the development environment. We're gonna go ahead and implement a trigger that keeps the full name updated for us in the database, based on changes that occur against the first name and the last name by the update. Now it's likely we would have to write one of these for the insert statement as well,
but we're just going to do it for the update at this point. And then, of course, we wouldn't need one for delete because the whole records gone.
So with that said, Let's go ahead and get started and let's take a look at this trigger I've already designed. We're gonna walk through the code and discuss what it's doing,
so we dropped the trigger. If exists, that's a common code block that occurs above use procedures and so on, so that we can always run this script. And when do the ah delimit er swapping that occurs in a lot of the other places, too?
Then we create a trigger. Akeem Attica were in the axiomatic a database, but I'm being explicit with this. So even if I don't have a database selected indie beaver, it will run against this database,
and I'm titling it users before update full name.
So the way I like to code my triggers in my databases is table name,
the time frame in which it occurs. It occurs before the update and what it's updating. So full name.
So just by looking at the trigger name, I got a good sense of what the trigger is doing now. That's not always easy to do, depending on how complicated things are getting. But if you can make it the code, explain itself as you read it.
It's very useful to new programmers and even you when you come back after six months and have to look at the way something's being done.
Next is just the syntax sugar that brings a trigger together. So before update on axiomatic, Adat users for each row begin.
If old first name
is not equal to new first name
old, last name is not equal to new last name. Then set the new full name
equal to a cat nation of the new first name comma that in parentheses, comma space, comma, new last name. And if
so, the effect of this trigger is it's real simple, but it keeps a column updated for us on the user stable. So let's go ahead and run This
Okay says I haven't air. Let's try this again.
All right, Iran. I must add something highlighted.
And that's now in there.
And let's see if we can see these triggers. So let's refresh
uses before update full name.
There it ISS. Now let's go to the users table and give it a try. So let's take Ian,
who is picking in and name him John.
I'm gonna go ahead and put that change in save.
Okay, that didn't change. But let's refresh.
Now we have John pick
and let's just try the last name of Ross in er clicks save.
Go ahead and click. Refresh. Now we have John Ross.
All right,
So as we can see,
the full name is changing in response to a trigger that occurs after or to be precise before update of the first name and last name fields. So now we don't have to worry about the full name. Now, Trigger will watch that for us.
So that completes this section of the lesson. Let's go ahead and head over to the summary,
and that brings us to the 7.4 summary
and this lesson review Trigger scope and implementation. We implemented a trigger for updating the full name. We discussed a good code pattern to promote self documenting code
and remember to practice good form with your triggers.
Triggers have gained a bad rap in the industry due to a lot of bad and confusing implementations. So save yourself some of that pain and start off on the right foot. So that completes this lesson and I hope to see in the next Thank you
Up Next