Is it good to have job details in the job queue table itself or have the details in a separate table?

Question

I am currently designing a module where a service or console application will be reading Job from a JobQueue table. I have designed the JobQueue table with the following info in it:

JobId: int Primarykey

JobType: int notnull

State: varchar notnull

CreatedOn: datetime notnull

LastModifiedOn: datetime nullable

CompletedOn: datetime nullable

The JobType attribute is mainly introduced to keep this table more generic, than towards particular type of job. My question is whether to keep the details for the job to be executed in this table itself or some other table with job id referencing it? This is because i have the data available in some other table. So while executing the job we can indirectly fetch the data. To avoid duplicating the info, i thought of something like this. Is this a good approach? Need your advice on this

Answer 1

Keep whatever data you have in that "other table" in that table. What you need to consider here is how you are going to use the data.
If you are going to display some indexed job from where one can select one to view the details, you can get your data in two separate fetches. Or if you need to all the data (data in JobQueue table plus data in that "other table") related to a job, you can always execute a single fetch with JOINs. I don't think keeping JobDetails data on a separate table would cause any issue.

Answer 2

I don't see many attributes here (maybe you did not show those?)

I see an id (jobID) clearly needed, type and state information (can't see how you can do without this data.)

And then you have auditing information, created, modified, and completed. Myself I like to put a string in there for who created and who modified, but I have that auditing information in every table I create. It is always useful when you are not sure what happened and you are trying to maintain the database.