【问题标题】:EF 4.1 SQL Compact byteEF 4.1 SQL 压缩字节
【发布时间】:2011-06-10 21:14:50
【问题描述】:

我的查询遇到了一些性能瓶颈。当我在实体中将属性作为字节引入时,会发生什么情况,EF 4.1 在使用它之前将其转换为 int。给定的代码将解释:

var segmentQuery = workUnit.SegmentRepository.GetQuery()
                                             .Where(x => x.FileId == file.Id)
                                             .Where(x => x.StateValue == (byte)SegmentState.Unhandeled)
                                             .OrderBy(x => x.Index);

很好地翻译为:

SELECT 
....
FROM ( SELECT 
    [Extent1].[Id] AS [Id], 
    ...
    [Extent1].[StateValue] AS [StateValue]
    FROM [Segments] AS [Extent1]
    WHERE ([Extent1].[FileId] = @p__linq__0) AND (0 = [Extent1].[StateValue])
)  AS [Project1]
ORDER BY [Project1].[Index] ASC

但是,在上面的例子中:StateValue 实际上是一个整数,这对于我的要求(4 种不同的状态)来说已经足够了,但是当将它更改为一个字节时,我得到:

SELECT ...
FROM ( SELECT 
    [Extent1].[Id] AS [Id], 
      ...
    [Extent1].[StateValue] AS [StateValue]
    FROM [Segments] AS [Extent1]
    WHERE ([Extent1].[FileId] = @p__linq__0) AND (0 = ( CAST( [Extent1].[StateValue] AS int)))
)  AS [Project1]
ORDER BY [Project1].[Index] ASC

由于该表一天可能包含超过 100 000 行,因此它的 State 字段仅占用 1 个字节的空间效率(尽管幸运地不是必需的),但是,更改为字节会杀死我的查询。

我做错了吗?有什么我可以做的吗?这个“问题”是否已知?

谢谢!

** 更新 **

[Flags]
public enum SegmentState : byte
{
    Unhandeled,
    Downloaded,
    Invalid,
    Assembled
}

在我的实体中:

/// <summary>
/// Dont use this, use SegmentState instead
/// </summary>
[Required]
public byte StateValue
{
    get { return _stateValue; }
    set { _stateValue = value; }
}

public SegmentState State
{
    get { return (SegmentState)StateValue; }
    set 
    {
        if (State != value)
        {
            StateValue = (byte)value;
            RaisePropertyChanged(StatePropertyName);
        }
    }
}

【问题讨论】:

  • 你能发布StateValue and SegmentState`的类型吗?如果您正在处理大量数据,那么我认为 SQL CE 无法处理它们

标签: c# .net entity-framework entity-framework-4 sql-server-ce-4


【解决方案1】:

真的不要使用 EF - 这将是你一生中最大的痛苦。 看看 C# 中的 MASSIVE 和 Dynamics - 它会让你大开眼界;-)

【讨论】:

  • 啊哈,回答我不喜欢听 ;) 我只是将我普通的旧 Sql DB 层换成了一个整洁的 EF 4.1 层。尽管存在一些问题(例如这个),但它在许多方面都很棒。幸运的是,我总是可以回退到 EF 中的普通旧 SQL 查询(但不是)。
  • Massive 也很棒,但它也有它的缺点,当我真的不需要时,我不喜欢使用动态。我选择 .NET 和 C# 是有原因的,我想坚持下去
  • 只要您不以性能为目标,EF 可能是一种选择 ;-)
  • 我们不应该在这里开始讨论,但是....您的部分错误。 EF 并没有优化到适合高性能的程度,但它做得很好(尤其是在智能 SQL CE 查询规划器到位的情况下)。我已经看到大量 linq 语句变成了高度优化的 SQL 查询,我不会再编写任何更优化的了。 EF 绝对是一个选择。 (我知道客户端的性能问题,但即使这样也可以解决,虽然仍然比大规模的要慢,我同意,但这只是一小部分)
  • 检查 dapper 并看到 EF 流血致死。 code.google.com/p/dapper-dot-net
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-07-06
  • 2012-09-16
  • 2013-06-12
相关资源
最近更新 更多