I consider this a judgement call.

Problems with SQL in code:

• Your code has a dependancy on SQL, if you change to a different flavour of SQL you'll have to troll through all your code to fix any non portable SQL.
• If your database table structure changes (e.g. new not null columns in a table into which you are inserting data) your code may fall over at run time - having all the SQL in one place makes it easier to test.

Problems with abstracting SQL:

• As mentioned earlier, very difficult to do for complex queries.
• You need to refer to several modules to understand what your code is doing. Having in line queries makes it very easy to quickly read and understand simple code.
• You limit what you can do with SQL to what your interface lets you do - some of the more powerful SQL features such as sub queries would be hard to build into an interface.

  e.g.
  
  select * 
    from rate 
   where id = ? 
     and rate.date_effective = 
    (select max(date_effective)
       from rate down_the_way
       where down_the_way.id = ?)
  [download]

My preference is that, for a large application, there should be a single module dealing with each data entity in your database (e.g. invoice.pm for invoices) and this module should provide interfaces to SQL to access data from that table. The perl and SQL are combined in the same module.

No outside module should access the data structures other than through this module. This is database centric however and can be tricky to map onto OO.

"The future will be better tomorrow."