> > > I'm just messign about with linq at the moment.
> > >
> > > I was wondering if there is a standard way to map between linq
> > structures.
> > >
> > > i.e. I have a normalised database schema created in the designer, I
> > don't
> > > want to bind to this directly but obviously to some slightly
> > denormalisied
> > > version of it.
> >
> > I don't see the 'obvious' part in that remark. For FETCHING, it
> > might be handy to have denormalized data in some areas, but for saving
entities,
> > you definitely want to stick to the abstract entity definitions in your
> > program's reality, not some denormalized pile of tables.
>
> UI usually operate on schema's that are derived and
> denormalised...though I accept that in MS world this is less true.
what does 'MS world' have to do with it?
If you denormalize data, that's in general only done for performance
reasons. What you refer to isn't denormalizing data, it's creating new sets
based on entity instances in the DB via projections on joined sets. This data
is by definition readonly.
> > Denormalization for performance purposes therefore isn't useful
> > for entities. It's only useful for new sets, derived from the entity
> > instances, e.g. all orderid's with the customer's companyname joined to
it.
>
> Generally front end show all sorts of data that is derived or
> denormalised from the underlying data, a simple grid map contain several
> joins, sometimes it makes sense to display those joins in separate
> grids, often not.
Though that's readonly data if it's presented in a single set. You can
create that easily with linq queries, that's the purpose of querying on top of
a normalized model:
var q = from c in nw.Customers
join orders o in nw.Orders on c.CustomerID equals o.CustomerID
select new { o.OrderID, c.CompanyName};
you then bind the q to a grid, done. You create new sets using projections. If
you want to 'extend' entities to contain data from other entities, you're IMHO
not doing yourself a big favor, as the model is then in theory wrong, plus you
get problems when saving data.
> > So take a look at indexed views. These are stored as-is and therefore do
> > offer performance optimizations. You then should be able to map an entity
onto
> > such a view. Just for fetching of course, Saving data should be done with
> > normal entities.
> >
>
> Ok I'll take a look, but I'm not really interested in performance...I
> simple want to map a normalised collection of Linq data
>
> Customer & orders & location....to a denormalised/derived one (Customer
> extended to include derived orders and location) & orders......
so you want to create a parallel hierarchy to customer-order-location?
FB
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
