Foundations of Programming - Karl Seguin

Chapter 6 - Object Relational Mappers
Stored procedures are faster
This is the excuse I held onto the longest. Write a reasonable/common SQL statement inline and then
write the same thing in a stored procedure and time them. Go ahead. In most cases there’s little or no
difference. In some cases, stored procedures will be slower because a cached execution plan will not be
efficient given a certain parameter. Jeff Atwood called using stored procedures for the sake of better
performance a fairly extreme case of premature optimization. He’s right. The proper approach is to take
the simplest possible approach (let a tool generate your SQL for you), and optimize specific queries
when/if bottlenecks are identified.
It took a while, but after a couple years, I realized that the debate between inline and stored procedures
was as trivial as the one about C# and VB.NET. If it was just a matter of one or the other, then pick
whichever you prefer and move on to your next challenge. If there was nothing more to say on the
topic, I'd pick stored procedures. However, when you add an O/R mapper into the mix, you suddenly
gain significant advantages. You stop participating in stupid flame wars, and simply say "I want that!".
Specifically, there are three major benefits to be had with O/R mappers:
1. You end up writing a lot less code – which obviously results in a more maintainable system,
2. You gain a true level of abstraction from the underlying data source – both because you’re
querying the O/R mapper for your data directly (and it converts that into the appropriate SQL),
and because you’re providing mapping information between your table schemas and domain
objects,
3. Your code becomes simpler- if your impedance mismatch is low, you'll write far less repetitive
code. If your impedance mismatch is high you won't have to compromise your database design
and your domain design - you can build them both in an optimized way, and let the O/R mapper
manage the mismatch.
In the end, this really comes down to building the simplest solution upfront. Optimizations ought to be
left until after you've profiled your code and identified actual bottlenecks. Like most things, it might not
sound that simple because of the fairly complex learning to do upfront, but that’s the reality of our
profession.
Foundations of Programming Copyright © Karl Seguin www.codebetter.com
45