LINQ: use stored proc or Ad-hoc?

dparsons · December 31st, 2008, 06:34 PM

It maintains state over active results sets.

It is my understanding that a DBML file is not connected to the datastore all of the time it only connected when you are working with data or are making queries against the DBML file and thus the data store.

Remember, the DBML file is just a bunch of classes that are representations of your physical tables, it doesn't actually contain any data so when you run XYZ query of course it is going to have to connect to the database preform XYZ query and return.

hth.
-Doug

eramgarden · December 31st, 2008, 10:34 PM

we have like 400 tables in our database. Is it ok to have all of it in a Datacontext? to have ONE datacontext to contain the tables/stored procs and just use this thru out the app?

dparsons · December 31st, 2008, 11:03 PM

O.o Wow, that sounds like a data-warehouse or a poorly designed database!

I have not read anything that would indicate that L2S can not support that many tables but, to me, it would seem a management nightmare because the DBML file is not "aware" of the database. What this means is that if a DBA or database programmer goes in and changes a varchar(10) field to varchar(5) , for example, and doesn't inform you your app will start spiting out truncation erros!

This isn't a huge deal since you can simply go into the DBML file and "refresh" it so that it updates itself to mirror the database . This really isn't any different then any other DAL issue but it is worth pointing out.

My other fear would be that the DBML file would grind VS to halt trying to render all of the tables and such this isn't to much of a problem as long as you aren't trying to work with said file but it would definately be something id look into.

hth.
-Doug

eramgarden · December 31st, 2008, 11:31 PM

i wanted to have separate DBML files for each section of the app/group of tables but my coworker put all the tables in one DBML file.

Isnt it better to have DBML files for each group of tables? She says it's easier to have one DBML file. Easier to compile and maintain.

eramgarden · January 1st, 2009, 12:31 AM

http://www.sidarok.com/web/blog/cont...rformance.html

step number 2 says not to dump everything in one datacontext.

eramgarden · January 2nd, 2009, 08:41 PM

We set the Default Tracking mode to off/false. Is that ok??

coworker did it because she couldnt serilaize the datacontext.

dparsons · January 4th, 2009, 03:30 PM

You are starting to ask questions that I can't really answer. The things that you are doing are, obviously, specific to the project that you and your co-worker are working on. To this end, it is counter productive for you to come here and "check up" on the things that your co-worker is doing to make sure if they are "ok". In an ideal world you and your co-worker would be talking about these types of things and weighing the pros and cons of each decision and looking at how the decision will ultimately affect the application.

Whether or not you should do this depends on the objects. If the objects in question are going to be updated, deleted, and so on then I probably would not turn tracking off. If, however, you are only using this objects for readonly operations, then it should not be a problem.

And you should probably read this article as well:
http://www.west-wind.com/Weblog/posts/313037.aspx

hth.
-Doug

eramgarden · January 4th, 2009, 03:32 PM

thanks. I work with a narcissist. I'm serious. So, i have to double check everything before i open my mouth. Thanks. You've been very helpful. I also bought a book and will go thru that as well.