Skip to main content
8 events
when toggle format what by license comment
Sep 13, 2012 at 22:04 review First posts
Sep 14, 2012 at 20:41
Sep 12, 2012 at 20:54 comment added RationalGeek @Nik I'm not just concerned about runtime performance but also design- and build- time. I've read some horror stories of using EF models against DBs of this size and have Visual Studio choke on them.
Sep 12, 2012 at 0:43 comment added Nik You control how little or how much you want to saturate the object graph.
Sep 11, 2012 at 22:30 comment added hanzolo i would say massive object trees and a normalized data structure go hand hand when dealing with large schema's
Sep 11, 2012 at 20:06 comment added Nik Forgot to mention that you can always tweak your performance when accessing your data. Look at lazy/eager loading options and which child entities you're bringing in. I see no reason why a full model would behave worse than a smaller one if you're not loading massive object trees.
Sep 11, 2012 at 20:04 comment added Nik If the OLTP performance is sufficient with the full-model approach, go with that. You can always break it up later if you have to, but the quickest and most agile way is to load the whole thing. You may never need the performance gains you get by breaking it up, so you'd by wasting time and making your system more complicated for no reason. Then there is the question of which model would you stick a new table/entity to when you decide to expand. And what happens when you need to run an update across multiple models. Save yourself the headache unless you really don't have an alternative.
Sep 11, 2012 at 20:00 comment added RationalGeek This seems like a good strategy, but doesn't really address the question of how to divide entities across different EF models. Do you have all entities in one model or do you divide and conquer in some way?
Sep 11, 2012 at 19:23 history answered Nik CC BY-SA 3.0