Можно ли заново создавать множество соединений SQL (SQL 2008)? - PullRequest
Новая
       14

Можно ли заново создавать множество соединений SQL (SQL 2008)?

1 голос
/ 27 марта 2010

При выполнении многих вставок в базу данных у меня обычно будет такой код: 

using (var connection = new SqlConnection(connStr))
{
  connection.Open();
  foreach (var item in items)
  {
     var cmd = new SqlCommand("INSERT ...")
     cmd.ExecuteNonQuery();
  }
}

Теперь я хочу разделить базу данных, и поэтому мне нужно выбрать строку подключения на основе вставляемого элемента. Это заставило бы мой код работать так: 

foreach (var item in items)
{
  connStr = GetConnectionString(item);
  using (var connection = new SqlConnection(connStr))
  {
    connection.Open();      
    var cmd = new SqlCommand("INSERT ...")
    cmd.ExecuteNonQuery();
  }
}

Что в основном означает создание нового соединения с базой данных для каждого элемента. Будет ли это работать или воссоздание соединений для каждой вставки вызовет ужасные издержки?

Ответы [ 3 ]

3 голосов
/ 27 марта 2010

Я полагаю, вы говорите о C # /. NET. В этом случае соединения объединяются платформой, поэтому затраты на их создание не так велики.

Редактировать

Как указано @TomTom, транзакции также должны быть приняты во внимание. Если вы выполняете вставки в разные базы данных на одном и том же сервере, вы можете использовать для этого обычную транзакцию SQL. Если базы данных находятся на разных серверах, вам необходимо использовать транзакцию MSDTC для координации их между серверами баз данных. В любом случае лучший способ обработки транзакций - это завершение соответствующего кода в TransactionScope. Это не конфликтует с открытием и закрытием (в действительности повторным использованием из пула) соединений с базой данных. 

using(new TransactionScope())
{
    // Update code to various databases, opening and closing connections.
}

В SQL2005 или новее TransactionScope по умолчанию сначала будет использовать транзакцию SQL, а затем автоматически преобразовывать ее в транзакцию MSDTC.

1 голос
/ 27 марта 2010

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

http://research.microsoft.com/apps/pubs/?id=76507

2.3 Определение возможностей для массовых операций

Рассмотрим цикл в приложении код, показанный ниже, внутри которого приложение вставляет данные в таблица: 

for (int i=0;i<MAXVALUE;i++) {
// execute SQL statement INSERT INTO T VALUES(...)
}

Как написано выше, код неэффективно, так как каждый раз через цикл оператор INSERT казнены. Гораздо более эффективный способ достичь того же результата, чтобы использовать массовая вставка API доступа к данным слой, который использует в своих интересах пакетирование. Обратите внимание, что ингредиенты для выявления этой проблемы имеет контекст приложения, который конкретный оператор SQL выполняется неоднократно внутри цикла, и контекст базы данных, чтобы знать, что каждый экземпляр на самом деле вставка Постановка на стол Т. Тогда можно положить эти кусочки информация вместе, чтобы предложить сопоставление с API-интерфейсами массовой вставки.

В ADO.NET 2.0 я думаю, что это означает использование SqlBulkCopy

1 голос
/ 27 марта 2010

Теоретически, можно создавать столько соединений, сколько вы хотите.Воссоздание соединения выполняется быстро, если только вы не принудительно создадите пул без подключения.Стандартные соединения SQL не закрываются, а помещаются в пул (на две минуты, iirc) для повторного использования.

При этом, если вы открываете новое соединение для каждой вставки, с которой вы столкнулись с серьезными проблемами, - ваша транзакцияграницы.Более сложные обновления должны попадать под одну транзакцию.В то время как вы МОЖЕТЕ просто обернуть это в пространство имен System.Transaction ... ... это будет означать, что все соединения будут оставаться открытыми до фиксации, используя МНОГО их, и это вызовет MSDTC (координатор распределенных транзакций)вмешиваться - со всеми накладными расходами, которые у него есть.

Таким образом, повторное использование соединений гораздо более целесообразно с архитектурной точки зрения. Вы в основном зашли в тупик из-за своего транзакционного поведения, а не из-за количества соединений..

...