I was looking through the forums the other day and noticed that someone wanted to track changes to the Agent jobs on their instance. However, they couldn't find a DDL trigger to capture the changes to a job. That's because a job is really data in a table, in dbo.sysjobs, dbo.sysjobsteps, etc. in msdb. To capture changes to a particular job, one would need a DML trigger that captures the insert/update/delete actions on these tables. You could also use XE, Audit, or some other feature that can track data changes in the msdb tables.

I'm not sure that makes sense to me. This week I'm wondering if any of you feel that SQL Agent jobs aren't well integrated into SQL Server.

Do you think that jobs should be a first class database citizen and managed with CREATE JOB, ALTER JOB, etc. DDL commands?

I think so. In fact, this would be the first step (in my opinion), towards getting jobs as a more useful database work process. Let's have a job system that handles automated mechanisms inside the database as actual objects we can manage, set permissions on, and control just as we do other objects. Let's treat these objects for what they are, actual items in SQL Server that should be objects.

Could this be implemented? Sure. In fact, I think this might be one of the best ways to start containing jobs inside of a database. Make them a first class object inside a database. We can use msdb as the container for instance wide jobs. Then any sort of scheduler, including SQL Agent, could use an API to pick up the code from within the database and execute it however they determine is best.

I don't think this is simple or easy, but it's possible. It would take some engineering effort from Microsoft, but I'm confident they could build a great ssytem. Making a job a first class citizen could help us control and simplify everything to security to transfer of the work from instance to instance. When the database moves, so does all the work associated with it.