Well, of course it’s possible. You don’t specify your database type, or backend language, or anything specific, so any answer you get will be pretty general. But if you were to have a job
table, or document, and the original project number were associated with that, then each of the other documents/tables would simply reference that.
For example, assume a SQL type database, you might have a jobs
table, with fields like the following:
id int auto_increment primary_key,
client_id int foreign_key,
title text,
description text,
...
… so that would be created when any step of the process is initiated, and as each step of the process initiates, they’ll simply use this id as their job_id
. They’d likely still have their own internal id field, like so:
table sample_requests
----------------------
id int auto_increment not_null primary_key,
job_id int foreign_key,
...
then, when you reference that (via PHP or perl or whatever, you’d build the tracking number as you see fit - the prefix would indicate the job step (SR
), and the job number would let you reference specifically which sample request record to fetch.
Are you likely to have multiple sample-request or samples for a given job? In that case, you could give each a secondary tracking number, by adding a secondary key, like S-12345-164
(for example). That 164
on the end would be the sample record’s unique id. This would allow the job id to be used in multiple samples, but the id field would render each unique.
Without more specifics, this is a thought experiment, but the short answer is yes, it is very feasible.