Re: What's the best module to stop mixing SQL with Perl?

I've gotta agree with the stored procedure/view solution, despite the fact that I despise it in practice (since it when I've seen it suggestied, it's to pull the power away from the developers and hands it to the DBA), but it does have genuine speed benefits and keeps all the SQL out of your code.

I know that Basset's persistent object can map multiple tables into a single object, and I think it does it pretty well and efficiently. But, as I've said in another thread, I'm biased (being the author and all). It's heavily supported, but not widely used, so you may find it difficult to work with. If so, I'd love to hear about it. Suggestions very welcome.

Simple SQL::Abstract might be useful, too. Instead of having sql statements all over the place, you'd be using it to construct queries for you. You end up with the same stuff, but it's much easier to abstract out the table or column names to central locations. Yeah, yeah, you can do it with plain old statements, but it'd probably be a bit cleaner by using SQL::Abstract with a few custom brewed containers around it.

Comment on Re: What's the best module to stop mixing SQL with Perl?

Replies are listed 'Best First'.
Re^2: What's the best module to stop mixing SQL with Perl? by jhourcle (Prior) on Sep 09, 2006 at 19:28 UTC
I've gotta agree with the stored procedure/view solution, despite the fact that I despise it in practice (since it when I've seen it suggestied, it's to pull the power away from the developers and hands it to the DBA), but it does have genuine speed benefits and keeps all the SQL out of your code. I have the (dis?)advantage that I'm both the developer and the DBA. And the few times that I've had a dedicated DBA that wasn't me, they were still willing to let me write all of the code. (I just had to go through them to make changes). The main advantages to views and stored procedures (at least in Oracle), is that I can tune the SQL with hints on indexes to use (or not use) and force the method of joins (eg, a sort-merge is typically better for getting all records, but a correlated join may look faster to the user if I'm paginating it) I specifically don't like like the various modules to remove my access to the SQL, as they haven't given me the level of control that I want for tuning. (yes, I know I'm picky, but in one project, it was the difference between 0.62 sec to generate a webpage, and 0.10 sec, partially due to optimizing the table joins and use of materialized views but also removing some ineffective indexes, pinning tables in memory and creating some multi-column indexes for the most queried fields).	[reply]

Replies are listed 'Best First'.

Re^2: What's the best module to stop mixing SQL with Perl?
by jhourcle (Prior) on Sep 09, 2006 at 19:28 UTC

I've gotta agree with the stored procedure/view solution, despite the fact that I despise it in practice (since it when I've seen it suggestied, it's to pull the power away from the developers and hands it to the DBA), but it does have genuine speed benefits and keeps all the SQL out of your code.

I have the (dis?)advantage that I'm both the developer and the DBA. And the few times that I've had a dedicated DBA that wasn't me, they were still willing to let me write all of the code. (I just had to go through them to make changes).

The main advantages to views and stored procedures (at least in Oracle), is that I can tune the SQL with hints on indexes to use (or not use) and force the method of joins (eg, a sort-merge is typically better for getting all records, but a correlated join may look faster to the user if I'm paginating it)

I specifically don't like like the various modules to remove my access to the SQL, as they haven't given me the level of control that I want for tuning. (yes, I know I'm picky, but in one project, it was the difference between 0.62 sec to generate a webpage, and 0.10 sec, partially due to optimizing the table joins and use of materialized views but also removing some ineffective indexes, pinning tables in memory and creating some multi-column indexes for the most queried fields).

[reply]