score:2

Accepted answer

unless you go for simple classes (poco etc), your own implementation is likely to have nearly as much overhead as datatable. personally, i'd look more at using tools like linq-to-sql, entity framework, etc. then you can use either linq-to-objects against local data, or the provider-specific implementation for complex database queries without pulling all the data to the client.

linq-to-objects can do all the things you mention, but it involves having all the data in memory. if you have non-trivial data, a database is recommended. sql server express edition would be a good starting point if you look at linq-to-sql or entity framework.

edited re comment:

regular tsql commands are fine and dandy, but you ask about the difference... the biggest being that linq-to-sql will provide the entire dal for you, which is a huge time saver, as well as making it possible to get a lot more compile-time safety. but is also allows you to use the same approach to look at your local objects and your database - for example, the following is valid c# 3.0 (except for [somedatasource], see below):

var qry = from row in [somedatasource]
          group row by row.category into grp
          select new {category = grp.key, count = grp.count(),
              totalvalue = grp.sum(x=>x.value) };

foreach(var x in qry) {
    console.writeline("{0}, {1}, {2}", x.category, x.count, x.totalvalue);
}

if [somedatasource] is local data, such as a list<t>, this will execute locally; but if this is from your linq-to-sql data-context, it can build the appropriate tsql at the database server. this makes it possible to use a single query mechanism in your code (within the bounds of lola, of course).

score:0

why not use a local database like sqlserver ce or firebird embedded? (or even ms access! :)). store the data in the local database, do the processing using simple sql queries and pull the data back. much simpler and likely less overhead, plus you don't have to write all the logic for grouping/aggregates etc. as the database systems already have that logic built in, debugged and working.

score:0

yes, you can use linq to do all those things using your custom objects.

and i've noticed a lot of people suggest that you do this type of stuff in the database... but you never indicated where the database was coming from.

if the data is coming from the database then at the very least the filtering should probably happen there, unless you are doing something specialized (e.g. working from a cached set of data). and even then, if you are working with a significant amount of cached data, you might do well to put that data into an embedded database like sqlite, as someone else has already mentioned.

score:1

you'd be better off letting your database handle grouping, filtering and aggregation. datatables are actually relatively good at this sort of thing (their bad reputation seems to come primarily from inappropriate usage), but not as good as an actual database. moreover, without a lot of work on your part, i would put my money on the datatable's having better performance than your homegrown data structure.


Related Query

More Query from same tag