Этот вопрос относится к задаче квотирования ресурсов. Обычно администратор желает контролировать ресурсы сервера, которые являются исчерпаемыми или дорогостоящими. Например, занятое место на диске, объём выделенной памяти, процессорное время. Если ваше приложение подключается к СУБД напрямую с клиентской рабочей станции, а не опосредованно через сервер приложения, то таким дорогостоящим ресурсом могут стать открытые сеансы.
Разумеется, разработчик приложения может и, как правило, должен экономить открытые соединения. Для этого у него есть удобные инструменты. Но если приложение запускается на разных рабочих станциях разными пользователями, то от действий разработчика зависит уже не всё.
Пределы на число одновременно открытых подключений можно установить и на сервере баз данных. В SQL Server’е для этого можно использовать триггеры входа (LOGON TRIGGER). Эти триггеры срабатывают после аутентификации (то есть мы уже знаем кто и с какого компьютера желает подключиться), но до создания сеанса (то есть, у нас ещё есть возможность не допустить установления соединения).
В контексте такого триггера вы можете обращаться к системным функциям и представлениям, что даёт возможность принять решение об отмене создания сеанса.
Например, можно проанализировать число уже открытых соединений с этой рабочей станции (здесь мы не даём открывать более 10 сеансов с одного компьютера)
или число открытых сеансов именно этого пользователя
Разумеется, можно использовать более сложную логику, анализируя уже открытые сеансы по пользователям, компьютерам и приложениям одновременно.
Обратите внимание, что триггеры входа действуют в рамках всего SQL-сервера. Поэтому обращайтесь с ними очень аккуратно. Если вы допустите ошибку в таком триггере, то подключиться к серверу не сможет никто, включая системного администратора, так как сервер будет сбрасывать любые попытки соединения
