Bath.pm April 2 Meeting Report

[Colin M Strickland]

Aaron Trevena writes:
 > 
 > ..coming from someone who only finished migrating to Postgres from MySQL a
 > few months ago ;)

 Over a year ago, actually , and hardly my fault it took so long to
 come about . In fact that particular database migration project was
 initiated under my suggestion, I had immediately argued the
 inadequacies of MySQL for the sort of database usage the company in
 question was attempting from my very first day on the job. This
 informed by a decade of experience designing relational database
 systems, some of them terrifyingly large. I merely meant to express
 solidarity with the idea of SQL being considered a crap language; it
 is if you only have access to crippled impementations of it.

 > 
 > 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. As ever in the real
world the rulebook can only ever be considered as heuristics. Always
these shades of grey , always ruining my beautiful application design
principles ..

-- 
Regards,
Colin M Strickland -- "Tape My Beatworm!"