Salesforce.com can connect to REST- and SOAP-enabled database servers. Unfortunately, older database servers, such as MySQL, do not support these modern protocols, instead depending on drivers and binary software libraries to expose their interfaces. ODBC is another common example of a "pre-Internet" protocol-- it relies on the existence of system drivers to provide the interface.
This means that, ultimately, any solution with Apex Code requires a middle-man approach. PHP can connect to MySQL and ODBC drivers, for example, so it would be possible to set up a server running PHP that can listen for incoming requests, translate the incoming request into a format that the other database system can understand, execute the command, then return the results back in REST or SOAP format (depending on the exact configuration of PHP code).
At the time of this answer, a cursory search on several popular search engines suggest that there is no open-source solutions written in PHP (or Perl, Ruby, ASP, JSP...) that addresses this need. However, there is an abundance of data on the Internet on how to write various scripts in any modern server scripting language, so it would simply be a matter of stitching that information together into a single coherent script.
Strings Are Immutable
You can't actually "modify" a string. Every time you do something that fundamentally alters even a single character in the string, you've actually created a new string. This prevents some awkward behavior that keeps certain object-oriented behaviors from happening compared to if you wrote your own string class. I thought I'd clarify that, since many people don't actually realize that they're not "modifying" strings.
Many Functions Are Useful Tools
Functions are great tools, and many of the methods in the String Class are awfully convenient, including String.toUpperCase, String.toLowerCase, String.escapeXml, and so on. They let you not have to worry about doing specific tasks, because they're solved problems. String.repeat is especially useful when you need large, repeating strings, for example, as it can actually perform thousands of times faster than writing your own loop.
Some Functions Are Merely Convenience Tools
However, functions like String.format are not your friend. String.format does not really "solve" a problem. First, it's a function, which means there's a performance penalty per call, and second, the only thing it's really good at, putting positional arguments anywhere, is rarely so useful that you'd actually "want" to use it instead of just using "+". It can't even accept an array of Object values to allow for formatting Dates, Booleans, Integers, and so on.
Which Is More Flexible
"+" and "+=" handle can handle most primitive data types, and all custom types that have a Object.toString method, but requires loops when you don't know how many elements are involved. String.format can support String values and nothing else, and the format string has to be either hard-coded or built on the fly, in which case, it's useless because you may as well build the string yourself. String.join has problems with custom Object.toString methods, but works very quickly with most primitive data types, and can handle arbitrarily long lists of random data without too much trouble. It's preferred for variable length strings instead of building your own loop.
Which Is More Efficient
The specialty functions that skip the mess of allocating memory repeatedly are some best functions in the library and are literally more efficient than anything you could write in Apex. String.format, while a nice tool to help you visualize string construction, is a function that's nearly useless in terms of performance. It's about 6 times slower than "+", and it can't even handle non-String values, like numbers, Boolean values, and so on. String.format will never outperform "+" and "+=", but it sometimes makes code easier to read.
The functions that are useful for getting new strings efficiently include most of the functions in the string class, even String.join if you have a variable/unknown number of strings to join at once. However, you should avoid using any function that's duplicated by an operator ("+", "+=", "=="), because those are only convenience methods that will slow down your code. For example, String.equalsIgnoreCase is the same as "==", but requires way more code, is slower than "==", and throws NullPointerExceptions. It literally has no purpose in the library that I could find, yet people use it because it's there.
Summary (tl;dr)
Use operators when at all possible. They will always outperform any function call by a large margin. However, do use functions that are purpose-built to do "just one thing", and make sure you keep checking the String Class with every release, as many of those functions are useful. String.format should be avoided in most cases, especially in a loop, but can be useful to make code more legible when you have a large number of values you want to string together (but, arguably, I'd still rather use String.join).
Best Answer
This seems timely as Grumpy just popped out of the developer console at me.
As per @sfdcfox's comment and answer to the linked question.
There are references to them back in 2009. See Salesforce, Snow White and the Seven Dwarfs and The Silver Lining - Meaningful Error Messages #94.
I suspect anyone who can tell you exactly where they are in relation to the database has probably signed a non-disclosure agreement. That doesn't mean we can't make some wild conjectures.
The presence of Oracle error codes like ORA-00001 and ORA-20191 plus the java.sql.SQLException would indicate they are some sort of layer immediately above the database running Java.
Its also interesting that they tend to bypass the GACK. Either they aren't being caught by the GACK mechanism or they are being rethrown. The latter seems unlikely. Why surface these errors rather than the generic GACK message. So the dwarfs live outside the standard application GACK error handling.
Why are there only 7? I'd assume it has something to do with the way Salesforce scales. Each instance/pod, e.g. na7, may have exactly 7 dwarfs. There are never any more or less and they would stand up a new pod rather than scale out the dwarfs. If you've got seven fixed servers I guess you are either naming them after dwarfs or deadly sins. Getting errors from Happy are probably better than errors from Lust or Gluttony.
Here's slide 8 from a Salesforce.com -architecture talk that I've defaced with where I think the dwarfs roughly reside in relation to the servers that makeup a pod and it's database cluster.
Here's another diagram from The Force.com Multitenant Architecture pdf.
The Query Servers might be in about the right place and performing the expected dwarf functions.
In Performance Monitoring and Testing in the Salesforce Cloud the Pod is shown as "30 plus servers" being used for Application,API, and Search servers over a "8 Node RAC cluster". I've never done infrastructure at that scale, but I suspect there is something working between all those servers and the database cluster.
See also: * Quora: What does Salesforce's infrastructure look like?