>>
It seems to be the same as saying that it is messy and wrong to have bits and pieces of regexes left [...]
The key difference here is that regexen are not generally considered to be a seperate language, where as SQL quite definately is. It's fairly common to expect any perl programmer to be at least vaugely familiar with regexen but not necessairly familiar with SQL.
Three advantages I can think of off the top of my head are:
- Familiarity - I can have someone who specializes in databases review my sql to make sure it is well formed and optimized without having to much with excessive amounts of perl, where as the perl programmer who doesn't know sql can just as easily only focus on the perl parts, as all he has to do is call some function if he wants data.
- Modularity - I could easily reuse sql statements and so on, a change in one place can instantly change everything that relies on this piece of code
- Portability - it becomes much easier to write applications to work on multiple databases when the SQL, the actual code that interfaces with the database, is hidden behind one or more abstraction layers.