I use MS SQL Server 6.5 most often. But, I also use Oracle 8.0 and MS SQL Server 7.0. In one regard, I consider this highly fortunate since I get exposure to the differences in each DBMS, and in the communication layers of the DBI with each of them. In another, it makes it highly difficult to write optimized code for a single architecture (since I want the single piece of code to be able to do the same work with each type of database).

My own worst experience is with MS SQL Server 7.0, as opposed to my more favorable experiences with 6.5. Oracle can be "difficult" at times. 7.0 gave me my worst experience when I first attempted to connect to it via the DBI. I ultimately ended up using DBD::ODBC, only because there were mitigating circumstances with the boxen I was using that would not work with DBD::Sybase / FreeTDS and a failed attempt with DBD::FreeTDS. This was done on site, which is two states away, and as such, hindered my overall progress but garnered me some support from within their IT department. Being unrelentless is very impressive to government employees, who (pardon my generalization if you are a government employee) tend to be unrelentless until 5:00 and then go to happy hour and only get back to being unrelentless around 8:00 the next morning.

The database should do all the work it should do. How's that for vague? Seriously, I recall this discussion recently, but have neither the patience or the general clue where this was discussed. What seemed to be determined in this discussion is that certain tasks make more sense dependent on the purpose of the system. If your system is dealing with tables that are small, grab them all into a hash structure according to how you need them via the database (no conclusion was drawn on whether sorting made more sense in the DBMS or Perl). But if the system is dealing with large sets of data, then it is best to let the database do what it does (keep data in a fairly organized fashion) and only rely on Perl to do the immediate task.

I guess I fall into the latter category, even with small systems. I consider myself a minimalist when it comes to coding, and so if I need X from the database, I don't grab Y for good measure. Grabbing Y is inherently not good measure if you only need X.

The line is thus drawn based on the fact that my systems need speed as their overall bright point. I don't expect to have an accountant taking my money when I go to deposit my check in the bank. Likewise, I don't expect Perl to be worried about more data than is necessary. (slightly bad analogy, and I'm calling myself on it before anyone else can.) But my point is while Perl could handle it all, there's overhead in the duplication process. And while an accountant could do the job of a teller, it reduces the overall workload that s/he can perform without the added responsibility. So, in a sense, my code is only as good as the other programmers at work, since I have to trust that none of the other code they produce results in unnecessary overhead with duplication. That way the actual system running all of this code can be optimally performing its tasks and reflect that with all of the code that it runs.

I'm going to get off of my soapbox now, and leave this as it is. I think I've given a fair enough look into how I approach the situation, and I am happy that this thread came up. ++ for jptxs for asking.

ALL HAIL BRAK!!!