Linq 中的临时表——有人发现这个问题吗？

Question

在尝试解决：

Linq .Contains with large set Causes TDS error

我想我偶然发现了一个解决方案，并且我会想看看这是否是解决问题的正确方法。

（简短的总结）我想对未（完全或至少容易）在 SQL 中生成的记录 ID 列表进行 linq-join。 这是一个很大的列表，并且经常超出 TDS RPC 调用的 2100 项限制。 因此，我在 SQL 中所做的就是将它们放入临时表中，然后在需要时加入该表。

所以我在 Linq 中做了同样的事情。

我添加了：

<Table Name="#temptab" Member="TempTabs">
  <Type Name="TempTab">
    <Column Name="recno" Type="System.Int32" DbType="Int NOT NULL" 
          IsPrimaryKey="true" CanBeNull="false" />
  </Type>
</Table>

打开设计器并关闭它，在那里添加了必要的条目，尽管为了完整起见，我将引用 MyDB.desginer.cs 文件：

   [Table(Name="#temptab")]
   public partial class TempTab : INotifyPropertyChanging, INotifyPropertyChanged
   {

           private static PropertyChangingEventArgs emptyChangingEventArgs = new PropertyChangingEventArgs(String.Empty);

           private int _recno;

#region Extensibility Method Definitions
partial void OnLoaded();
partial void OnValidate(System.Data.Linq.ChangeAction action);
partial void OnCreated();
partial void OnrecnoChanging(int value);
partial void OnrecnoChanged();
#endregion

           public TempTab()
           {
                   OnCreated();
           }

           [Column(Storage="_recno", DbType="Int NOT NULL", IsPrimaryKey=true)]
           public int recno
           {
                   get
                   {
                           return this._recno;
                   }
                   set
                   {
                           if ((this._recno != value))
                           {
                                   this.OnrecnoChanging(value);
                                   this.SendPropertyChanging();
                                   this._recno = value;
                                   this.SendPropertyChanged("recno");
                                   this.OnrecnoChanged();
                           }
                   }
           }

           public event PropertyChangingEventHandler PropertyChanging;

           public event PropertyChangedEventHandler PropertyChanged;

           protected virtual void SendPropertyChanging()
           {
                   if ((this.PropertyChanging != null))
                   {
                           this.PropertyChanging(this, emptyChangingEventArgs);
                   }
           }

           protected virtual void SendPropertyChanged(String propertyName)
           {
                   if ((this.PropertyChanged != null))
                   {
                           this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
                   }
            }
    }

在我的 MyDB.dbml 文件中， 代码。 我通常会遇到的情况是：

MyDBDataContext mydb = new MyDBDataContext();

我必须让它与普通的 SqlConnection 共享其连接，以便我可以使用该连接来创建临时表。 之后它似乎非常有用。

string connstring = "Data Source.... etc..";
SqlConnection conn = new SqlConnection(connstring);
conn.Open();

SqlCommand cmd = new SqlCommand("create table #temptab " +
                                "(recno int primary key not null)", conn);
cmd.ExecuteNonQuery();

MyDBDataContext mydb = new MyDBDataContext(conn);
// Now insert some records (1 shown for example)
TempTab tt = new TempTab();
tt.recno = 1;
mydb.TempTabs.InsertOnSubmit(tt);
mydb.SubmitChanges();

并使用它：

// Through normal SqlCommands, etc...
cmd = new SqlCommand("select top 1 * from #temptab", conn);
Object o = cmd.ExecuteScalar();

// Or through Linq
var t = from tx in mydb.TempTabs
        from v in  mydb.v_BigTables
        where tx.recno == v.recno
        select tx;

有人认为这种方法作为在 Linq 中的联接中使用临时表的通用解决方案有问题吗？

它很好地解决了我的问题，因为现在我可以在 Linq 中进行直接连接，而不必使用 .Contains()。

后记： 我确实遇到的一个问题是，在表上混合 Linq 和常规 SqlCommand（一个在读/写，另一个也在读/写）可能会很危险。 始终使用 SqlCommands 在表上插入，然后使用 Linq 命令读取它效果很好。 显然，Linq 缓存结果——可能有一种解决方法，但并不明显。

Answer 1

我认为使用临时表来解决您的问题没有问题。 至于混合 SqlCommands 和 LINQ，您对危险因素的看法是完全正确的。 使用 DataContext 执行 SQL 语句非常容易，我什至不用担心 SqlCommand：

private string _ConnectionString = "<your connection string>";

public void CreateTempTable()
{
    using (MyDBDataContext dc = new MyDBDataContext(_ConnectionString))
    {
        dc.ExecuteCommand("create table #temptab (recno int primary key not null)");
    }
}

public void DropTempTable()
{
    using (MyDBDataContext dc = new MyDBDataContext(_ConnectionString))
    {
        dc.ExecuteCommand("DROP TABLE #TEMPTAB");
    }
}

public void YourMethod()
{
    CreateTempTable();

    using (MyDBDataContext dc = new MyDBDataContext(_ConnectionString))
    {
        ...
        ... do whatever you want (within reason)
        ...
    }

    DropTempTable();
}

Answer 2

我们也有类似的情况，虽然这有效，但问题是您并没有真正处理 Queryables，因此您无法轻松地“使用”LINQ。 这不是一个适用于方法链的解决方案。

我们的最终解决方案只是将我们想要的内容放入存储过程中，并在需要这些值时在该过程中针对临时表写入选择。 这是一种妥协，但两者都是解决方法。 至少使用存储过程，设计器将为您生成调用代码，并且您有一个黑盒实现，因此如果您需要进行进一步的调整，您可以严格在过程中进行，而无需重新编译。

在完美的世界中，未来将会支持编写 Linq2Sql 语句，允许您在查询中指示临时表的使用，避免在像这样的复杂场景中使用令人讨厌的 sql IN 语句。

Answer 3

作为一种“通用解决方案”，如果您的代码在多个线程/应用程序中运行怎么办？ 我认为大列表解决方案总是与问题领域相关。 最好使用常规表格来解决您正在处理的问题。

我曾经在数据库中创建了一个“通用”列表。 该表由三列创建：int、uniqueidentifier 和 varchar，以及用于管理每个列表的其他列。 我想：“应该足以处理很多情况了”。 但很快我就收到了一项任务，要求对三个整数的列表执行联接。 之后，我再也没有尝试过创建“通用”列表。

另外，最好创建一个 SP，以便在每次数据库调用时将多个项目插入列表中。 您可以在不到 2 db 的往返时间内轻松插入约 2000 个项目。 当然，根据您在做什么，性能可能并不重要。

编辑：忘记它是一个临时表，临时表是每个连接的，所以我之前关于多线程的论点是不正确的。 但它仍然不是强制执行固定模式的通用解决方案。

Answer 4

尼尔提供的解决方案真的有效吗？ 如果它是一个临时表，并且每个方法都在创建和处理自己的数据上下文，那么我认为在连接断开后临时表不会仍然存在。

即使它在那里，我认为这将是一个你假设查询和连接最终如何呈现的一些功能的区域，这就是 linq to sql 的一些大问题 - 你只是不知道他下面可能会发生什么跟踪工程师提出更好的做事方法。

我会在存储过程中完成它。 如果您愿意，您始终可以将结果集返回到预定义的表中。