How to avoid using a cursor in this T-SQL example - sql-server

Question

I'm converting a VBA application to run natively in a set of Microsoft SQL Server stored procedures. Since I'm using recordsets in VBA the direct translation would be to use a cursor in SQL Server. Unlike some other databases, SQL Server has terrible performance with cursors and I see advice to avoid them like the plague. So I'm looking for advice on a direct way to code this problem.
I have a set of tasks and a set of people to work those tasks. There are rules so that only certain people can work certain tasks. The goal is to distribute the tasks as evenly as possible to the people.
The VBA algorithm is:
Select all the tasks for a given rule.
select the single person who matches that rule who has the lowest number of tasks assigned to them. Requerying each time to assure that I get the person with the lowest number after each update.
Assign that person to that task.
Increment the person's count of tasks assigned.
Next Task
If not end of Task goto 2.
The only ways I see to do this are with a cursor or a real ugly while loop. With a cursor the logic moves over with the same steps from the VBA application.
The WHILE Loop I envision in pseudo code:
While exists unassigned tasks
select a single task
select the person with the least tasks that can work that task type
assign person to task
Increment person's count
Does anyone have any better suggestions?

Answer 1

Not everything should be done in a stored procedure. This sounds like a scenario where you might select all the datasets, process assignment on client side (or SQLCLR), then push back the results.
Unless the problem is so massive to prevent it (millions of people, tasks, and rules), keeping it outside of the database should keep it more maintainable.

Answer 2

I'm new here but have been writing SQL/stored procedures like this for a few years.
Anyway, I've found that there are some times you cannot avoid a cursor (or while loop, etc) - particularly when the results of the next iteration depend on the results of this iteration. This applies in your case, as you're assigning tasks based on how many tasks they have.
The good news is that, based on what you're doing (assigning people to tasks) I'm guessing you're only talking very small numbers of loops and/or only running infrequently. As such, a cursor should still work fine.
The key thing to be mindful of in this is to keep the code within the cursor as simple as possible and ensure you don't need to keep doing big reads/etc. Instead, do any harder coding outside the cursor to get the data in a reasonable format (e.g., in temp tables) then run the cursor over the top.

Answer 3

Since you do not give us the structure of the table, it's kind of hard to try to give you a solution that will suit your needs. Of course, this is only an example of how you can rethink your logic, it's up to you to adapt it, specially based on the volume of your dataset which i assume must be small, and fill the gap for how you apply the rules which person can be assigned to which task
But, here's a strategy you can use (only if you understand it, since you'll have to maintain it!).
Let say you have theses tables:
create table Task (id int identity(1,1) not null, taskname varchar(30));
create table Person (id int identity(1,1), name varchar(30) not null);
create table AssignedTask (id int identity(1,1) not null, idPerson int not null, idTask int not null)
with theses values :
insert into Task (taskname) values ('Task1'),('Task2'),('Task3'), ('Task4'), ('Task5'), ('Task6'),('Task7'),('Task8'),('Task9'),('Task10')
insert into Person (name) values ('Person1'),('Person2'), ('Person3'), ('Person4')
insert into AssignedTask (idPerson, idTask) values (1,3),(2,4),(4,1),(4,5)
The current situation is :
select p.id, p.name, 'is assigned to', t.id as TaskId, t.taskname
from AssignedTask at
inner join Person p on p.id = at.idPerson
inner join Task t on t.id = at.idTask
order by p.name
id name TaskId taskname
----- ----------- -------------- ----- ---------
1 Person1 is assigned to 3 Task3
2 Person2 is assigned to 4 Task4
4 Person4 is assigned to 1 Task1
4 Person4 is assigned to 5 Task5
The idea behind this logic is to "pre-compute" the order of which the task will be assigned by computing the number of already assigned task + a row number and then, sorting the data by the least.
-- unassigned task with a TaskSequence to be able to perform an join on a row number by NbAssignedTaskIfAssigned
;with UnassignedTask as (
select row_number() over (order by id) as TaskSeq, id
from task
where id not in (select idTask from AssignedTask)
)
-- Get Number of task assigned by person
, PersonTask as (
select idPerson, count(1) as NbAssignedTask
from AssignedTask
group by idPerson
)
-- this is where the logic is
, ExpandThis as (
select p.id as PersonId, coalesce(pt.nbAssignedTask,0) as nbAssignedTask
-- this allow us to prioritize which person should be assigned a task
, coalesce(pt.nbAssignedTask,0) + row_number() over (partition by idPerson order by idperson) as NbAssignedTaskIfAssigned
from Person p
left join PersonTask pt on pt.idPerson = p.id
-- this is where the magic happens. Since you did not provides us how
-- the rule for assignment is enforce (either in a table on in code),
-- i choose to not apply any rule at all, so every person can be assigned
-- to any task. Change this line to a "cross apply ( select .... from
-- MyRules where ... ) x" to fit you needs.
cross apply UnassignedTask x
)
, Prioritize as (
select *
-- Just use a basic row_number to order which row must be assigned first
, ROW_NUMBER() over (order by NbAssignedTaskIfAssigned) as [Priority]
from ExpandThis et
)
select p.PersonId, ps.name, t.id as TaskId, t.taskname
from Prioritize p
inner join UnassignedTask ut on ut.TaskSeq = p.[Priority]
inner join Person ps on ps.id = p.PersonId
inner join Task t on t.id = ut.id
order by p.[Priority]
and the result is :
PersonId name TaskId taskname
----------- --------------- -------- ------------------------------
3 Person3 2 Task2
3 Person3 6 Task6
1 Person1 7 Task7
2 Person2 8 Task8
2 Person2 9 Task9
4 Person4 10 Task10
Person 3 did not have any assigned task, so he comes first. Second, third and fourth rows are both equals (assuming task 2 is assigned to person3), so they get assigned the next 3 tasks. Finally, all four person have now an equal number of task assigned but only 2 tasks remaining, the first 2 persons get assigned. you can fiddle this by modifying the order by clause.
Now, you can insert this result into AssignedTask, no need of a cursor nor a loop to perform this task.