April 10, 2014 at 8:18 pm
It seems as though .net database technologies are starting to really take off and consume a lot of the responsibilities that have traditionally been handled by SQL Server.
There is the statement. Let me supplement that with... I don't know the right answers from here on out and I am searching for some good input and or articles to research.
Entity Framework. Is it an evil word or do you embrace it?
I have used it, I like it, its very powerful, ts cool, its new, its fun... but is it good?
You can still fire off stored procedures through Entity Framework easy enough, but it seems developers don't like to.
Do you have any personal experience or have you read any good articles that speak to performance metrics for either side?
I'm really looking for some info here on Linq execution times vs stored procedure execution times.
Personal experience... we have some MVC sites that carelessly fire 100 linq queries to build a simple page. We've rebuilt those pages to use stored procedures to return more information per call. This improved durations on the sql server, but not dramatically. Where we really saw improvement was on the web server performance.
MVC... and dare I say it Code First with database migrations.
If you are not familiar with this concept... Right now there is a trending technology allowing developers to quickly build their own relational databases whilst coding their .net projects.
I'm expecting a good audience here to speak against it. My money is on a skilled DBA over a skilled Dev 10 times out of 10 when it comes to database architecture.
Fair question though... Is there an upside? Have you had any experiences where your developers used this technology and then you worked with them to tighten up the model?
Does Code First scare you?
I apologize if this has already been hashed out on the forums 1000 times, Links to those discussions would be appreciated as well! (I did not find any)
April 11, 2014 at 4:46 am
There's been tons of discussion around this. Coding Horror has an article[/url] about one of the best articles on ORMs, that and all the links are worth a read.
I've worked on several projects using different ORM tools. I'd say that about 2/3 of those projects either fail or become horrific battlegrounds. The 1/3 that succeed are the ones that actually decide to use the Object to Relational Mapping tool to do exactly that, map between the objects that developers love and the relational storage that DBAs, well, I don't LOVE it, but I recognize the need of it. And then, there are some amount of the code, probably reads, that won't work from the generated code, so you need to write T-SQL and probably keep it accessible in a stored procedure (perish the thought). In short, the successful projects play to the strengths of developers and DBAs. It's the adversarial ones that fail (and the conflict comes from DBAs just as much as from developers).
I'm all in favor of getting developers to do what they do. Code First. Great. Agile. Fine. You name it, I want to help you do it well. But, if we decide that a relational data store is the right way to go... it just sort of makes sense that we do the relational data store correctly. That's all. I cover some of this in my talk on database deployment[/url].
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 2 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply