Calculating SLA times - DB or code?

I would like to know what are the cons and pros of calculating the SLA in code each time we present the data vs. running a process, which will update on each day the SLA fields inside the DB.
What is the standard (if exist such(.
Who is Participating?
sybeConnect With a Mentor Commented:
You don't calculate a Service Level Agreement from values in a database, or do you?

generally however:

Databases can do some simple calculations as SUM, MAX, AVERAGE, but a database is not really meant for complex calculations.

Programming languages (code) are designed to do calculations (among other things), but depending on the complexity of the calculation, you have a performance hit.

So it really depends. If the calculation is complex and the page gets 5,000 hits/minute you are better of to have the calculation done once per minute (or hour) and have people look at a not-totally updated result.

Or you could update the result only when something changes the result, like some changed or new data in the database.

Well, the pros of doing it in code at runtime is that you actually can see your preformance in relation to the SLA in real time. If you only calculate say, once per 24 hrs, you can actually be uncompliant for like 23:59:59 without knowing it You're unlucky?!?

Normally the easiest way would be to store the required response / resolution time along with the request once it's created and then simply compare at runtime.

SLA? What does that stand for in this case?
Cloud Class® Course: SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

My guess would be Service Level Agreement?
carlnorrbomConnect With a Mentor Commented:

That's why in my recommendation above I suggested to store the target respone / resolution time along with the original request in the DB. This way, the check whether or not things are compliant to SLA (i.e. did we respond in time, resolve in time) is a matter of a simple comparison between the datetime in the DB and (simplified i know, but you get the point).

I have done this numerous times for servicedesk applications and such, there's really not right or wrong in this, just different angles and different requirements.

Hi again (sorry for being a pain ;-),

Just to clarify:

1. Request made -> Check SLA: Response 8 hrs, Resolution: 48 hrs -> Store in DB: Target Response = DateTime.Now.AddHours(8) & TargetResolution = DateTime.Now.AddHours(48)

2. Request checked in real time -> Check Response: Has the response time been stored in the DB? -> If yes, then:

- ResponseTime < TargetResponse = Compliant to SLA
- ResponseTime > TargetResponse = Failed through response

If no response time stored:

- DateTime.Now() < TargetResponse = Compliant to SLA
- DateTime.Now() > TargetResponse = Falied through response.

The same goes for resolution. Normally You would continously update the "status" of a request through the application, i.e.:

- New
- Open
- Pending/Idle
- Closed
- Etc.

You would update the database records for the request to reflect when changes in status are made, i.e:

"New" -> "Open" = Response Time
(("New" -> "Closed") - "Pending/Idle") = Resolution Time

Hope this thinking makes sense.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.