Это не обязательно сделано в БД. Как вы предположили, это дорого. Хотя БД может быть резервным хранилищем, вероятно, для сопровождения операции опроса используется более эффективный механизм, такой как сохранение статуса в реальном времени в памяти в дополнение к окончательному состоянию на БД. Вы можете опрашивать память намного эффективнее, чем ВЫБРАТЬ состояние из таблицы каждую секунду.
Кроме того, как я уже упоминал в комментарии, в некоторых случаях вы можете получить много пользы, подделывая внешний вид обновления статуса с помощью анимаций и т. Д., Используя оценку, реже проверяя источник данных.
Редактировать
(оптимизация для использования меньшего количества ресурсов БД в реальном времени)
Вместо того, чтобы опрашивать базу данных для каждого пользователя, чтобы проверять состояние задания каждые X секунд, немного измените поведение ситуации. Каждый раз, когда работа добавляется в базу данных, читайте базу данных один раз, чтобы поместить метаданные о всех работах в кеш. Так, например, кэш памяти будет отражать [user49 ... user3, user2, user1, userCurrent] 50 заданий пользователя, если по 1 заданию каждое. (Может быть, я должен был написать это как [job49 ... job2, job1, job_current], но та же идея)
Тогда веб-страницы отдельных пользователей будут опрашивать этот кеш, который всегда остается актуальным. В этом примере БД была прочитана только 50 раз в кеш (один раз за отправку задания). Если эти 50 пользователей ждут в среднем 1 минуту для обработки задания и опрашивают статус каждую секунду, тогда база пользователей опрашивает кэш в общей сложности 50 пользователей x 60 секунд = 3000 раз.
Это 50 операций чтения из базы данных вместо 3000 за период в 50 минут. (в среднем по одному в минуту). Кэш-память всегда свежая и обрабатывает нагрузку. Это гораздо менее страшно, чем рассматривать возможность попадания в БД каждую секунду для каждого пользователя. Вы можете хранить другие статистические данные и информацию в кэше, чтобы помочь с оценкой и тому подобное. Пока свежий кеш обеспечивает большую эффективность, он является жизнеспособной альтернативой массовым попаданиям в дб.
Примечание. Под кешем я подразумеваю глобальное хранилище, такое как приложение или стороннее решение, а не кеш страниц ASP.NET, который быстро выходит из области видимости. Кэширование с использованием механизмов ASP.NET может не подходить для вашей ситуации.
Другое примечание: БД будет знать, когда будет добавлена другая запись задания, независимо от того, откуда, поэтому триггер может инициировать обновление кэша.
Несмотря на хорошее решение для базы данных, очень много пользователей, которые часто опрашивают, могут создавать проблемы с подключениями к веб-серверу, и вам может потребоваться другое решение на этом уровне в зависимости от трафика.