My question is mainly concerned with “what’s best for performance”, but kinda “philosophically” speaking as well (if it makes a difference)… so let’s jump right in.
[TableA].[ColumnB] stores a value that needs to exist in [TableC].[ColumnD]. Right off the bat, no answers involving Foreign-keys – just assume that they’re “not allowed” in this environment for whatever reason.
But due to “circumstances x,y,z”, [TableA].[ColumnB] sometimes gets values that do not exist in [TableC].[ColumnD], because, let’s say, [TableA] gets populated from an object that exists in running code as a “serialized blob”, an in-memory representation of the data, and the [ColumnB] values got populated before those values were deleted from [TableC].[ColumnD] by some other process. ANYWAY, this is for example’s sake, so don’t get bogged down in the “why does this condition happen”, just accept that it does.
To “fix” the problem, which method is best of these two: 1. make a Trigger that fires on-INSERT on [TableA], to Update [ColumnB] to the value that it should be (and assume I have a “mapping” of bad-to-good values). Or, 2. run a scheduled-Job every hour/minute/whatever that runs Update queries to change all possible “bad” values to their corresponding “good” values.
To put it more generally, what’s better for performance and/or what is best practice: a Trigger, or a periodic Scheduled-Job? In context, let’s say [TableA] is typically on the order of hundreds of thousands of rows, with Inserts happening 10-100 records at-a-time, as frequently as every few minutes to as rarely as a few times per day.
On-insert.
Doing triggers is like callbacks- They’re more logically sound, and they spread any lag into every query. Doing continual checks (called polling or cron-jobs), you end up with more severe moments of lag every now and then. In almost all cases, using triggers/callbacks are the better way to go as having 1ms of lag added to every query is better than 100ms of lag at seemingly random intervals.