一个功能的多个 SqlConnections：坏主意？答案

【问题标题】：multiple SqlConnections for one feature: bad idea?一个功能的多个 SqlConnections：坏主意？
【发布时间】：2014-04-03 16:58:18
【问题描述】：

我有一个连接到我的 sql 数据库的 asp.net gridview。插入新记录或更新记录时，我会进行一些服务器端检查，然后更新/插入记录或什么也不做。现在我有 2 个方法 CheckArtistExists 和 CheckSongExists 都使用 SqlConnection 对象，例如

public bool CheckSongExists(string _title, int _artistId)
    {
        int cnt = -1;
        using (SqlConnection con = new SqlConnection(CS))
        {
            //check if song already is exists in DB
            SqlCommand cmd = new SqlCommand("Select Count(ID) from tblSong WHERE Title = @newTitle AND ArtistId = @newArtistId;", con);
            cmd.Parameters.AddWithValue(@"newTitle", _title);
            cmd.Parameters.AddWithValue(@"newArtistId", _artistId);
            con.Open();
            cnt = (int)cmd.ExecuteScalar();
            // if cnt ==1 song exists in DB, of cnt == 0 song doesnt exist
            if(cnt == 1)
            { return true; }
            else
            { return false; }
        }
    }

因此，对于 gridview 中的更新功能，我需要建立 3 个 SqlConnections（最多）一个来检查艺术家（如果艺术家不存在，我必须先向 tblArtist 插入一条记录）然后检查歌曲是否存在（仅当艺术家存在时），最后如果歌曲不存在，我必须插入一条新记录。

我知道数据库连接是宝贵的资源，所以我将它们放在 using 块中。所以我不太确定使用 3 个 SqlConnection 对象来更新/插入是否是好的风格。你能告诉我我的代码是否正常，或者我是否应该使用其他方法来解决这个问题。

谢谢

【问题讨论】：

标签： asp.net sql

【解决方案1】：

ADO.NET 在内部管理ADO-NET Connection-Pool 中与 DBMS 的底层连接：

实际上，大多数应用程序只使用一种或几种不同的连接的配置。这意味着在申请期间执行时，将重复打开许多相同的连接，并且关闭。为了最小化打开连接的成本，ADO.NET 使用称为连接池的优化技术。

连接池减少了新连接的次数必须打开。池子保持物理的所有权联系。它通过保持一组活动来管理连接每个给定连接配置的连接。每当用户在连接上调用 Open，池化程序会寻找可用的池中的连接。如果一个池连接可用，它将其返回给调用者，而不是打开新连接。当。。。的时候应用程序在连接上调用 Close，pooler 将其返回给池化的活动连接集，而不是关闭它。一旦连接被返回到池中，它已准备好在下一次公开通话。

所以显然没有理由避免创建、打开或关闭连接，因为实际上它们根本没有被创建、打开和关闭。这只是连接池的一个标志，用于知道何时可以重用连接。但这是一个非常重要的标志，因为如果一个连接“正在使用”（连接池假设），一个新的物理连接必须对 DBMS 开放，这是非常昂贵的。

因此，如果您“重用”连接，则不会获得任何性能提升，反之亦然。

创建、打开（在连接的情况下）、使用、关闭并在您需要的地方处理它们（例如在方法中）
使用using-statement 隐式处理和关闭（在连接的情况下）

所以是的，每种方法使用一个连接绝对没问题，因为如果启用了连接池（默认），您根本不使用物理连接。

另一个问题是您是否可以改进您的方法。您可以创建一个存储过程来检查存在并相应地更新或插入。

Solutions for INSERT OR UPDATE on SQL Server

【讨论】：