Normalt skal de undgås, men funktionen er der af en grund, og der er tidspunkter til at bruge dem. Jeg vil sige, at 90+% af de markører, jeg har set, ikke er nødvendige. Hvis du bruger dem til CRUD-operationer, kan det næsten altid laves om på en sæt-baseret måde. Jeg har ofte set folk bruge markører til dette, fordi de ikke ved, hvordan man bruger joins i en opdatering eller sletning, eller at de kan bruge en select-statment i stedet for en værdisætning i en insert. Endnu en unødvendig brug, når folk tror, de har brug for dem til en lidt mere kompleks behandling, som faktisk nemt kunne håndteres med en sagserklæring.
Markører er nogle gange hurtigere til at beregne noget som en løbende total.
Markører er også praktiske til flere udførsler af en lagret proc, der er sat op til kun at håndtere én inputværdi ad gangen. Jeg bruger ikke denne funktion til at køre brugerlagrede processer (medmindre jeg ved, at jeg vil ramme et meget lille sæt data), men den er meget praktisk for databaseadministratorer, når de skal køre systemprocesser mod flere tabeller.
Hvis du opretter e-mails i SQL (ikke det bedste sted at gøre det, men i nogle systemer er det der, de gør det) og ikke ønsker, at hele e-mailens publikum skal se de andre personer på listen, eller du vil personliggøre hver e-mail med oplysninger om adressaten, markører er vejen at gå.
Markører eller loops kan også bruges til at behandle batches af poster, hvis hele den sæt-baserede indsættelse/opdatering/sletning vil tage for lang tid og låse tabellerne. Dette er en slags hybrid mellem markørerne og den sætbaserede løsning og er ofte den bedste til store ændringer på produktionssystemer.