代码之家  ›  专栏  ›  技术社区  ›  David Veeneman

带SQL Compact/EF4的guid或int实体键?

  •  1
  • David Veeneman  · 技术社区  · 14 年前

    这是对 earlier question 我用sql compact发布了ef4实体键。SQL Compact不允许服务器生成的标识密钥,因此我只需要创建自己的密钥,因为对象被添加到 ObjectContext . 我的第一个选择是整数键,前面的答案链接到 blog post 它显示了一个扩展方法,该方法使用 Max 使用选择器表达式查找下一个可用键的运算符:

    public static TResult NextId<TSource, TResult>(this ObjectSet<TSource> table,  Expression<Func<TSource, TResult>> selector) 
        where TSource : class
    {
        TResult lastId = table.Any() ? table.Max(selector) : default(TResult);
    
        if (lastId is int)
        {
            lastId = (TResult)(object)(((int)(object)lastId) + 1);
        }
    
        return lastId;
    }
    

    以下是我对扩展方法的看法:如果 对象上下文 我正在使用的是一个未过滤的实体集。在这种情况下, 对象上下文 将包含数据表中的所有行,我将得到准确的结果。但是,如果实体集是查询筛选的结果,则该方法将返回筛选后的实体集中的最后一个实体键,这不一定是数据表中的最后一个键。所以我认为扩展方法不会真正起作用。

    在这一点上,显而易见的解决方案似乎是简单地使用一个guid作为实体键。那样的话,我只需要打电话 Guid.NewGuid() 方法在将新实体添加到 对象上下文 .

    我的问题是:有没有一种简单的方法可以从ef4获取数据存储中的最后一个主键(而不必创建第二个主键 对象上下文 为了这个目的?有没有其他理由不采取简单的方法,只使用一个guid?谢谢你的帮助。

    4 回复  |  直到 14 年前
        1
  •  3
  •   David Veeneman    14 年前

    我最后得到了一个导游。

    • 大小/性能问题不是 对于sql compact来说是关键的(甚至是显而易见的),因为 它是一个本地的单用户系统。 应用程序不会是 管理航空公司预订 系统。

    • 至少在这一点上 似乎没有办法绕过“不” “服务器生成密钥”的限制 SQL Compact/EF4堆栈。如果有人有一个聪明的黑客,我仍然愿意接受。

    这并不意味着我会在sql server或sql express中采用相同的方法。我仍然对整型键有明确的偏好,而sql compact的更大的同级允许它们与ef4一起使用。

        2
  •  1
  •   user276695    14 年前

    使用guid。具有实体框架的压缩框架不支持自动增量。

    另外,如果你想创建一个使用多个数据源的应用程序,int pk很快就会崩溃。

    • 使用guid,您可以强制调用guid.newguid()以获取新密钥。
    • 对于int,您必须点击数据库才能获得有效的密钥。

    如果将数据存储在多个数据库中,int-pk将导致冲突。

        3
  •  1
  •   Ian Mercer    14 年前

    我之前为sql ce做的,假设我们有一个访问数据库的应用程序,就是在启动时计算最大值,并将其放入一个静态变量中。现在,您可以轻松地分发序列值,并且可以使生成它们的代码非常容易地实现线程安全。

        4
  •  0
  •   ErikEJ    14 年前

    避免使用guid的一个原因是size=内存和存储空间消耗。

    您还可以查询SQL Compact元数据,如下所示:

    从“信息架构”列中选择“下一个自动增量” 其中table_name='categories'和autoinc_next不为空