Bath.pm April 2 Meeting Report

[Aaron Trevena]

On Sun, 14 Apr 2002, Colin M Strickland wrote:
> Aaron Trevena writes:
>  >
>  > ..coming from someone who only finished migrating to Postgres from MySQL a
>  > few months ago ;)
>  [ Colins brave fight against the legion of database problems and
>    implementations snipped ]

Yes, you are brave man. Unfortunately you will continue to get ever harder
database problems to solve until you reach for a high velocity rifle and
climb to a suitable vantage point ;)

>  > I have just been building a small library for a freelance project - it
>  > does all the database tasks required, abstracting away the actual SQL and
>  > queries - By designing the database naming, etc in such a way as to ease
>  > automation I was able to work out side tables, joins, etc and provide 8
>  > functions for all the database access in the application.
>
> This sort of stuff can work very well for certain applications. It can
> also lead to suboptimal performance for others. As you said, it all
> depends on the definition, and to a certain degree the complexity of
> the underlying data model. Sometimes excessively normal models can
> impose an unrealistic performace overhead, while providing a
> flexibility the application space will never need.

My plan is to use an abstraction layer for 95% of the work (which it
should do well 95% of the time) and then hack the remaining 5% using
something else but still asbtracted. Using non-standard code to solve
non-standard problems seems entirely reasonable.

I am especially pleased about how succesful the library has been - I'm
already working on a new version that is much improved and has a better
API. One of the main benefits is that the database is designed to work
with the software we have, and even when it doesn't it is predictable
enough and consistent enough to make programming around its limitations
easier.

The important thing is that it saves development time. If its quicker to
not use it I don't, but so far that hasn't happened. Unlike at work where
90% of the time its quicker to embed SQL in your code rather than call
dodgy VB objects that call even dodgier Stored Procedures... urgh!

The best bit is that most of web development and content management etc
uses only a very limited set of DB logic. And the bits that aren't within
that subset are the interesting bits you want to spend your time on :)

A.

-- 
Aaron J Trevena - Perl Hacker, Kung Fu Geek, Internet Consultant
AutoDia --- Automatic UML and HTML Specifications from Perl, C++
and Any Datasource with a Handler.     http://droogs.org/autodia