Re: Table bloat in Linq-SQL
- From: "Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xxxxxxxxx>
- Date: Sun, 11 Nov 2007 02:11:33 -0800
Andrus wrote:
You could partition your database into several contexts. Are you
sure this is actually an issue for you though? How much memory are
you seeing being used?
I'm sorry I was not clear.
The actual issue with that is that loading some of database tables
requires creating and loading additional assemblies at runtime.
Creating those assemblies requires some database access also.
Since all 500 tables are loaded always I'm afraid that creating
always all assemblies for all tables with database acess decreases
perfomance a lot.
So I'd prefer to create table objects only when required.
I'm looking for a way to modify database class to implement delayed
loading using table object getters or cache some data in isolated
storage or some other idea.
I think this is done to be able to create queries at runtime properly
from the expression trees. (otherwise the context will run into unknown
table references).
Why would you want to create these wrappers at runtime? Because that
way you can't program against them.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
.
- Follow-Ups:
- Re: Table bloat in Linq-SQL
- From: Jon Skeet [C# MVP]
- Re: Table bloat in Linq-SQL
- From: Andrus
- Re: Table bloat in Linq-SQL
- References:
- Table bloat in Linq-SQL
- From: Andrus
- Re: Table bloat in Linq-SQL
- From: Jon Skeet [C# MVP]
- Re: Table bloat in Linq-SQL
- From: Andrus
- Table bloat in Linq-SQL
- Prev by Date: our website provid Power-leveling service
- Next by Date: WPF grid sample
- Previous by thread: Re: Table bloat in Linq-SQL
- Next by thread: Re: Table bloat in Linq-SQL
- Index(es):
Relevant Pages
|