Re^3: arranging code that works with SQL databases in Perl

Yes, the thing is how much SQL manipulation do you need to do? For instance, do you sometimes need to add LIMIT clauses? Or count rows instead of just returning them?

Or maybe the columns you need back change dynamically?

Stored procedures and phrasebooks share some similar issues that dave mentions here

Comment on Re^3: arranging code that works with SQL databases in Perl

Replies are listed 'Best First'.
Re^4: arranging code that works with SQL databases in Perl by mje (Curate) on Jul 27, 2009 at 07:45 UTC
We don't do any SQL manipulation outside the database. If we need a result-set where one of the columns = X or like Y or some other comparison, the value being tested against is passed as an argument although the cases other than equality are almost non-existent. We have no cases of changing the number of rows in the result-set since there is a procedure/function which provides exactly what is required. I believe we've also got no occurrences of dynamic SQL in the packages. Perhaps we are lucky in being able to do this but I think it was more by design. The outside Perl knows nothing at all about the structure of the database tables, it only knows about the procedures and functions we expose from the packages. Even though this application is fairly large we've had no real problems making it this way and as the procedure and function interfaces are well defined we can work on the database side independently from the Perl (and other languages) on the outside.	[reply]

Replies are listed 'Best First'.

Re^4: arranging code that works with SQL databases in Perl
by mje (Curate) on Jul 27, 2009 at 07:45 UTC

We don't do any SQL manipulation outside the database. If we need a result-set where one of the columns = X or like Y or some other comparison, the value being tested against is passed as an argument although the cases other than equality are almost non-existent. We have no cases of changing the number of rows in the result-set since there is a procedure/function which provides exactly what is required. I believe we've also got no occurrences of dynamic SQL in the packages. Perhaps we are lucky in being able to do this but I think it was more by design.

The outside Perl knows nothing at all about the structure of the database tables, it only knows about the procedures and functions we expose from the packages. Even though this application is fairly large we've had no real problems making it this way and as the procedure and function interfaces are well defined we can work on the database side independently from the Perl (and other languages) on the outside.

[reply]