I think you will find many people on here that provide answers from similar experience to mine.
Over the last 12 years I have worked with MySql, PostgreSQL, SQLServer, Oracle.
More recently, NoSQL in the form of App Engine Datastore, SQLite in iOS development.
Any one of these are advanced and provide solid SQL standard capabilities. They also take turns in providing functionality outside of the standard. PostgreSQL has the most flexible license. If you work on windows primarily or even do Access programming you can use MSDE (microsoft desktop engine?) inside of Access instead of Jet. MSDE files can be directly mounted by SQLServer. So MSDE programming is SQLServer programming. The databases vary the most once you start programming code that runs inside the database. Also XML and OODB features are vastly different from database to database.
MySql and PostgreSQL are both quite feature rich...many of the old arguments from a few years ago no longer apply. Both are readily available in very affordable hosting plans. If you are a linux terminal wizard.. you may find that PostgreSQL's console interactions are little nicer. If you like to dable with opensource apps that use a database you may find more apps support MySql first and PostgreSQL second.
Platform independent. I am guessing you are asking Windows/Linux/Solaris/OSX/AIX..etc. The database providers work very hard to make their databases run on as many platforms as possible (except MS). Oracle has some additional .NET APIs that provide enhanced interop with the MS ecosystem. Outside of SQLServer, the database can run on most any platform.
Programming vs. Administration (DBA). You can sort of think of Programming as the development cycle activity and Administration as the production or rehearsing for production activity. DBA's usually are the gatekeepers and health workers of the database. They won't usually work too closely with application code riding layers above the database. Programmers will work and often code changes for the database but may have to get them cleared through the DBA. DBA's likely also have the heavy responsibility of ensuring the security and safety of the data.
Language can often be a factor, however if a company has a database, usually you will be using the same platform. These things can be a large investment in time and personel resources. Once you have a system that works and you have practices in place for working with it they typically want to stay with it.
Yes. a server somewhere. unless your app is not distributed. SQLite is a fairly capable database that can run with multiple clients. It is now in your webbrowser (HTML5) and on your iphone. It supports enough SQL to get you rolling. We may see more and more client side database development happening.
I can't really speak to game development.
Great Question. Words of wisdom I have heard from others.
A. The database is not a magical box. You must learn the complexity of what is happening under the hood. Queries on sizeable databases can take 2hours to return and if written differently may return in 2minutes. Know what is happening a level below what you are developing in. EXPLAIN is an SQL term that will show you the databases plan, this is a good place to start.
B. You can do very terrible things to a production database...You will be hard pressed to find a battle worn database dev/dba that hasn't accidentally blown away a table or updated all records to lastname='Prince Jr.' instead of just Freddy's. Respecting the power and magnitude of the mistakes that can be made.
C. If you use SELECT DISTINCT and now you are getting the result you want, make sure you know why.
D. UNION does something different than UNION ALL
E. When move a lot of data into or out of a database. Find out how to BULK LOAD/COPY/DUMP. Parsing and INSERT statement is expensive!
F. Bind variables!! Most adapters you will use to talk to a database will allow you to bind your variables.. "SELECT * FROM foo WHERE candy = ':1'" ('chocolat'). After the first time you run this the database will have a plan and know what to do again and again.
G. "SELECT *" should not be used in production code. It is for adhoc fooling around only.
H. Referential integrity is really good stuff. FOREIGN KEYS are your friend.