McGruff wrote:
I sometimes wonder if database access layers are a good option. OK, it makes things easier for the programmer but isn't there a speed penalty compared to writing a simpler script tuned to a specific database?
Should we write code which best suits our needs as programmers or code which best suits the needs of our clients, ie the fastest possible solution?
Classes in general might also get a mention in this context..
I hear exactly what you're saying. It seems that for the sake of the paradigm, we are comfortable with the OO speed hit. This isn't to say that OO is bad and/or should never be used. I use Objects as well. I just feel that in speed critical areas, and I consider dealing with a database to be one such area as it's one of the most lilely to become a bottleneck, objects aren't allways the best solution.
When I was doing a lot of messing around with the idea of structures in php, I found that abstraction could be acheived, ease of use, and with close to no speed hit compared to an OO approach. This ended up with Small Unit Raid. I guess it depends on just how much you really need in the way of functionality. If you don't need much, use Eclipse, if you want it all, use Adodb. If you want sheer speed, I say don't use objects at all (and give Small Unit Raid a look

).
Of course, from the viewpoint of a large team, many would consider the OO approach superior. In many of these cases, speed may not be the ultimate issue. Furthermore, it may be easier to create the entire thing using objects, get a product out the door, then come back later and tune specific areas of code (perhaps by taking a non OO approach) that may be bottlenecks.
To me, it's simple. If I'm worried about the ability to scale performance wise, then I'm more than willing to consider a non-OO tack.
Cheers,
BDKR