我正在制作一个复杂的应用程序(计划涉及:文章,销售,客户,制造,机器......),它使用ERP的SQL Server数据库提供的信息。
我使用了大约30个不同的相关对象,每个对象都将其信息存储在表/视图中。其中一些表有20k到100k的记录。
我需要将所有这些表转换为C#对象,以便将来无法在SQL中处理。我不需要所有的行,但是没有办法确定我需要哪些行,因为这将取决于运行时事件。
问题在于最好的方法。我尝试了以下方法:
检索所有数据并将其存储在
DataSet使用SqlDataAdapter
,在RAM中占用大约300mb。
这里的第一个问题是:同步,但它是可以接受的,因为数据还没有
在执行期间改变那么多。
然后我浏览每一行并将其转换为C#对象, 存储在静态字典中,以便通过密钥快速访问。问题在于创建如此多的对象(数百万)占用内存 使用量高达1,4GB,这太多了。除了记忆,数据 访问速度非常快。
因此,如果所有内存占用太多,我认为我需要某种laxy加载,所以我尝试了:
SqlDataReader
过滤项目我需要只有
第一次它是必需的,然后它存储在静态中
字典。这种内存使用方式是最小的,但这种方式
很慢(分钟顺序),因为这意味着我需要像服务器似乎不喜欢的那样的不同查询(低性能)。最后,我尝试了一种有效的中间方法,但我不确定它是否最佳,我怀疑它不是:
第三个选项是填充包含所有信息的DataSet
并存储本地静态副本,但不将所有行转换为对象,只需按需执行(懒惰),类似于这样:
public class ProductoTerminado : Articulo {
private static Dictionary<string, ProductoTerminado> productosTerminados = new Dictionary<string, ProductoTerminado>();
public PinturaTipo pinturaTipo { get; set; }
public ProductoTerminado(string id)
: base(id) { }
public static ProductoTerminado Obtener(string idArticulo)
{
idArticulo = idArticulo.ToUpper();
if (productosTerminados.ContainsKey(idArticulo))
{
return productosTerminados[idArticulo];
}
else
{
ProductoTerminado productoTerminado = new ProductoTerminado(idArticulo);
//This is where I get new data from that static dataset
var fila = Datos.bd.Tables["articulos"].Select("IdArticulo = '" + idArticulo + "'").First();
//Then I fill the object and add it to the dictionary.
productoTerminado.descripcion = fila["Descripcion"].ToString();
productoTerminado.paletizacion = Convert.ToInt32(fila["CantidadBulto"]);
productoTerminado.pinturaTipo = PinturaTipo.Obtener(fila["PT"].ToString());
productosTerminados.Add(idArticulo, productoTerminado);
return productoTerminado;
}
}
}
那么,这是一个很好的方法,或者我应该查看实体框架或强类型DataSet
之类的内容吗?
答案 0 :(得分:1)
我使用大约30个不同对象之间的关系,每个对象的信息都存储在表/视图中。其中一些表有20k到100k的记录。
我建议对不同类型的对象做出不同的决定。通常,具有数千条记录的表更有可能发生变化。记录较少的表不太可能。在我正在做的一个项目中,决定是在List<T>
中缓存不会改变的对象(在启动时)。对于几百个实例,这应该不到一秒钟。
如果您正在使用linq-to-sql,在List<T>
中有一个本地对象并且已正确定义FK约束,则可以obj.Items
访问由{{1过滤的Items表我的ID。 (在这个例子中,obj是PK,Items是FK表)。
此设计还将为用户提供他们期望的性能。当处理小集时,一切都是瞬时的(缓存)。处理较大的集合但进行小的选择或插入时 - 性能良好(使用PK的快速查询)。当你开始进行连接多个大表的查询时,你才真正受苦;在这些情况下,用户可能会期望这样(虽然我不能确定更多关于用例)。