>
> My point of view is that insisting to use another and another layers of
> abstraction just for the abstraction itself does not lead to good things.
> Table Gateway and Row Gateway patterns have their use, but they have
> limitations also and are not the best solution for everything.
>
Who is insisting that you use Table/Row Gateway for everything? Not me. I
definitely agree that OO abstractions for data access are less speedy than
writing SQL queries. I agree that they have their use, but no solution
should be employed in all situations.
Not every database query needs to be optimal. Some queries are done
infrequently. Many performance problems cannot be solved in a scalable way
with code alone -- you have to rearchitect, or use caching, or do
server-level scale-out. Performance optimization is a holistic process,
involving every level of software architecture (and some hardware
architecture too), so don't focus too much on any one part of it. Sometimes
writing SQL by hand is the best way to improve database access. Sometimes
it may be caching the query results.
You're right that encapsulation is a good OO principle, and centralizing the
database queries makes them easier to maintain than scattering SQL
throughout your code. But that doesn't necessarily mean that we need to
abandon the OO interface and write *every* SQL query by hand. What I
recommend is that we use OO classes for simplicity and convenience, and when
we find some code that is a bottleneck in the app because of using the OO
interface, then we can refactor that code to improve its performance.
My example of writing your own data store module, or abandoning PHP is
hyperbole on my part. I just mean to say that there's always a point of
diminishing returns when you choose coding techniques for the sake of
performance over development efficiency. Switching to programming in
assembler is of course a bad idea for 99.9% of web apps. But in very rare
cases, it could be exactly the right thing to do.
Where the balance point lies is determined on a case by case basis.
Sometimes you're writing a tiny little intranet app that has only six users
and doesn't need to be optimized -- but developing that app needs to be very
quick and easy, because it would senseless to invest months of effort for an
app to serve only six people. Other times you're working on a high-end
content management system for a highly scalable news site like Yahoo! Then
you can invest a lot of engineering time to optimize more for performance.
I think you and I are probably on the same page...
By coincidence, Rasmus Lerdorf gave a keynote at Drupalcon this week in
Hungary, and reportedly he said some things that support this too. He
compared a bunch of frameworks, and observes that they all have overhead
that makes them unsuitable for high-performance, high-scalability
applications. He even says that any scripting language (like PHP) is
unsuitable for very high-scale apps!
Here's an article reporting his speech:
http://www.sitepoint.com/blogs/2008/08/29/rasmus-lerdorf-php-frameworks-think-again/
Regards,
Bill Karwin
--
View this message in context: http://www.nabble.com/Zend_Db_Table-time-overhead---about-25--tp19203345p19206688.html
Sent from the Zend DB mailing list archive at Nabble.com.
没有评论:
发表评论