I usually go for the easiest thing to do that will match nicely the problem space. This is very often avoiding multiple layers of abstractions and objects, unless the project is very big and/or you're prepared to document it all in a apt way. Don't go for a solution that makes solving the problem harder at all, and try to keep separate things that can live one without the others. Don't go for a solution that everybody is chatting about or you read books about just because it's fashionable or academically "in".
One of the reasons why Unix is still around is that it makes it simple to create a "solution toolbox" that something else can then use.... so it makes solving the "big" problem a task of solving smaller ones and the glueing it all together. Re-use what you can, you won't be the first person ever trying to solve the problem you're facing.
Don't go for performace at first; unless your design is infeasible, CPU cycles cost less than your own time. And half-solved computing messes tend to get worse with time. Design for simplicity and understandabilty, play with the problem space, then decide. Perl can be a very good tool about this.
Just my euro 0.02... :-)
In reply to Re: Mixing Mysql and Perl
by l3nz
in thread Mixing Mysql and Perl
by SavannahLion
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |