Digging into databases

I’ve been thinking a lot about databases recently.

One of the reasons for this focus is my increasing focus on databases/dynamic sites, and my relatively recent exposure to databases.

Sure, I’ve done access and worked with sites that have run big databases, but until the last couple years I never really performed an ODBC connection.

Now I do it with alacrity and increasing frequency.

So I think more about it.

In a way, I have a good point of view: I have a solid background in Web design and, to a degree, application architecture. And while my database exposure has been relatively recent, I’m not a stodgy old man on this front: No, I’m not an expert in databases. But I sure wish I was. They change everything for a Web developer.

With all the tools I can bring to the table, I’m able to see the flaws and strengths of most databases — or at least the database/application nexus.

What I’m seeing, overall, is the following:

  • Badly designed databases (I’m as guilty of this as the next, but my mistakes stay on my home computer, they don’t run actual businesses).
  • Bad databases for open source (mySQL & postgresSQL, though both have their good points, as well: mySQL — installed base; postgresSQL — great database overall but for lack of tools).
  • Stupid, awkward database connections by programming languages (Perl, PHP, ASP for example). I’m spoiled: Even if you hate Cold Fusion — and many programmers do — you cannot deny that it is the easiest to connect to a database. Set up a DSN in an admin tool, and then to run a query and get results have to do all of this:


    select * from table


    How hard was that?

  • Uncomfortable database/application solutions. Use a Cold Fusion example again: To me, the best solution here is to run Cold Fusion on Linux (faster than on NT; way cheaper; more reliable) and MS SQL Server on NT/2000. Virtually no one does this. The platform wars are still hurting us, although things are getting better.