Рекомендации SQL CONNECTION

Question

В настоящее время обсуждается, каковы преимущества и недостатки наличия единой архитектуры подключения SQL.

Чтобы уточнить, что мы обсуждаем, при создании приложения откройте соединение SQL, а при закрытии приложения или ошибку закрытия соединения SQL. И вообще не создавать другое соединение, а использовать только это для связи с БД.

Нам интересно, что думает сообщество.

Answer 1

Закройте соединение, как только оно вам больше не нужно в течение неопределенного периода времени. Таким образом, соединение возвращается в пул соединений (если пул соединений включен) и может (повторно) использоваться кем-то еще.

(Соединения являются дорогостоящими ресурсами и иногда ограничены).

Если вы удерживаете соединение в течение всего времени жизни приложения, и у вас есть несколько пользователей для этого приложения (таким образом, несколько экземпляров приложения и несколько подключений), и если ваш сервер БД ограничен только x количество одновременных подключений, то у вас может возникнуть проблема ....

См. Также лучшие практики для ado.net

Answer 2

Следуйте этому простому правилу ... Открывайте соединение как можно позже и закрывайте его как можно скорее.

Answer 3

Я думаю, что это плохая идея по нескольким причинам.

1. Если у вас есть 10 000 пользователей, использующих ваше приложение, это 10000 открытых соединений постоянно
2. Если вам нужно перезапустить сервер Sql, все эти 10000 соединений будут признаны недействительными, и ваше приложение внезапно - при условии, что вы включили логику переподключения - будет выполнять 10000 почти одновременных запросов на повторное соединение.

Чтобы расширить пункт 1, вы должны как можно скорее закрыть соединения, потому что в противном случае вы израсходуете ограниченный ресурс на потенциально бесконечный период времени. Если вы настроили Sql Server для одновременной работы максимум 10 001 соединения, тогда ваше приложение может одновременно работать только с 10 001 пользователем. Если вы открываете / закрываете соединения по требованию, тогда ваше приложение будет масштабироваться намного дальше, так как вероятность того, что все активные пользователи одновременно используют базу данных, реально мала.

Answer 4

Но, с другой стороны, я бы слишком осторожно открывал и закрывал соединения. Это намного дешевле с пулом соединений, чем без него, но даже с пулом менеджер пула может решить увеличить или уменьшить пул, превратив его в дорогостоящую операцию.

Мое общее правило - открывать соединение, когда пользователь инициирует какое-либо действие, выполнять работу, а затем закрывать соединение, прежде чем ждать следующего ввода пользователя. Для любого данного нажатия кнопки «Обновить» или чего-либо другого, у меня обычно будет только одно соединение. Но вы определенно не хотите держать соединения открытыми во время ожидания ввода пользователя, если вы вообще можете помочь ему по всем причинам, упомянутым другими. Вы можете буквально подождать несколько дней, прежде чем пользователь нажмет другую клавишу или коснется другой кнопки - что если он оставит свой компьютер включенным и уйдет в отпуск? Привязка ресурса к непредсказуемому промежутку времени - плохая новость. В большинстве случаев истекшее время ожидания ввода пользователя намного превысит время выполнения реальной работы.

Answer 5

Я использую систему поддержки, называемую Richmond Systems, которая использует одно соединение на весь срок службы приложения, и, как пользователь ноутбука, это королевская боль сзади. Даже когда я ношу с собой ноутбук, скачков между точками беспроводного доступа достаточно, чтобы отключить соединение с БД. Затем программное обеспечение жалуется на соединение с БД, переходит в состояние ошибки и не закрывается. Его нужно убить вручную из диспетчера задач.

Короче говоря, НЕ ДЕРЖИТЕ ОТКРЫТЬ ПОДКЛЮЧЕНИЕ БАЗЫ ДАННЫХ БОЛЬШЕ, ЧЕМ НЕОБХОДИМЫМ.

Answer 6

Под прикрытием ADO.NET использует пул соединений для управления соединениями с базой данных. Я бы посоветовал оставить его в пуле соединений, чтобы позаботиться о ваших потребностях в соединении. Держать соединение открытым в течение всего срока действия вашего приложения - плохая идея.