Fetch(entity or collection, levels, types to include, types to exclude)

Fetch(fixtures, 1, typeof(Team), typeof(Venue))… you just call this in your service layer and default to lazy loading otherwise.. or define something on the domain entity to say what to types to get by default? I would be using ActiveRecord under the service layer.

While this isn’t one trip it would still be less than several 100 potential

public class Fixture
{
// This would be ignored as the deeploading options excldues this
[DeepLoad]
public Venue Venue
{
return this.venue;
}

[DeepLoad]
public Team HomeTeam
{
get
{
return this.homeTeam;
}
}

[DeepLoad]
public Team AwayTeam
{
get
{
return this.awayTeam;
}
}
}

the fetching strategy is going to take the most effort out of the 3 options, but it gives you the flexibility to optimize for each specific scenario that you encounter

My example query:

Fixture (say 100 of them)
Fixture.HomeTeam (type Team), Fixture.AwayTeam (type Team)

Stored procedures would be as its for an ORM … FixtureListAll, FixtureGetByID, TeamGetByID

Options I can see are either:

1.

FixtureList

and then work out what unique TeamIDs there is and then do a batch call on
TeamGetByID

So 2 trips to DB

OR

2.

FixtureList and deep load 1 lot of children underneath, so bring back the Teams also, but this would be for all entities so performance would be hit and miss

So 1 trip to DB but bring back more than you need
OR

3.

A fetching strategy and you create a single stored procedure like option 2 but only when you need it, so default to lazy load or something

So 1 trip but because you programmed for this you are aware of what your bringing back

Any advice/suggestions welcome

depends on the dataset in the referenced table… if it’s more likely that the number of needed records is somewhat similar to the number of records in the referring table then i’d just join the two in one query

if the number of needed records in the referenced table will be much smaller than the number of records in the referring table, i’d go for two statements and try to bring back only the ones i really need in the second statement. your stored procedure could then still send back both resultsets… with a datareader you can process each resultset returned by a statement so that wouldn’t be an issue

either way you do it, as long as you combine both operations in one stored procedure then you don’t really need to worry about the ‘overhead’ of a second query since you’re not really paying for the network latency of multiple remote calls

What would you suggest in regards to deep loading and using stored procedures, say you have a list of 100 of something each having a foreign key to another table … (using batch queries)

We have to use stored procedures at our place and I am looking at building our own basic ORM.

1. Get all of the list and the FK records
2. Get all of the list and attempt to get unique FK records (so you bring back less from DB).