I don't consider that spaghetti code, but it does have problems. The big one is the tendency to assemble queries by string interpolation....
What we've done in LedgerSMB is quite simple. All db statements in new code (outside the mapper functions) are in stored procedures. Everything is mapped in there using a Perl API so in the new code (post-1.2) otherwise all SQL is in one set of files and all Perl is in another, with minimal overlap.
This sort of thing makes for very clean development. No, spaghetti code is making me have 15 files open in VIM trying to figure out which of them has the function that is being called in it, with several candidates all bearing the same function name (oh, the horrors).
What we've done in LedgerSMB is quite simple. All db statements in new code (outside the mapper functions) are in stored procedures. Everything is mapped in there using a Perl API so in the new code (post-1.2) otherwise all SQL is in one set of files and all Perl is in another, with minimal overlap.
This sort of thing makes for very clean development. No, spaghetti code is making me have 15 files open in VIM trying to figure out which of them has the function that is being called in it, with several candidates all bearing the same function name (oh, the horrors).