Ever wonder what your database looks like?
Over breakfast yesteray morning, Archinodes collaborator Corina MacDonald and I had a pretty good nerd-out session about databases. So, before I forget, I am jotting down a few key ideas from our chat (much of the credit for these insights goes to Corina, but errors can be attributed to me as I parse out this information from a non sysadmin non programmer p.o.v.) ...in case anyone else out there was wondering what their database looks like, where it is hidden, and how they might go about accessing it once it is backed up.
The database is so huge conceptually, I can already feel this will be a multi-post post...but anyway, let's start somewhere.
People use the word database a lot more these days because computers are such a huge part of our daily lives and because databases are thought to be the all-encompassing word for what lives on and through the web. But beyond that general idea, what is a database? If we're so reliant on the database, I feel like we should have a better sense of what it is, what it does, and what its limitations are. I can't help but subscribe to the idea that databases are, like code itself, at the core of our digital cultures, so it follows that understanding a database should give us a better sense of the fragility AND enduring ephemerality of the web's form, assets, functionality, and contents and their relationship to one another. It might also reveal to be messier than we often make it out to be, if we picture tables and grids...
From phpMyAdmin (which you can usually access form your site's control pannel) we exported a .sql database (called a dump file) and opened it up in TextEdit. What this gives you, when exported from Drupal is a very long string of text (not what I was expecting!). The idea of the backed up database is that you should be able to toss this file back up through MySQL server (a site, which is a server really) which would then rebuild your tables and generate your site as it was... based on the series of commands listed in the file. However, this is not without serious issues, which I'll come back to in a later post, when I address the black hole of website preservation that is backward compatibility.
To compare, I also exported an .xml file from Wordpress to see if and how content management systems (CMS) structure databases differently. Because .xml is different from .sql --the details of which will also have to wait for a later post -- and I can report that the .xml is much tidier than the .sql to the human eye (at least based on my 2 exports). I can also say that importing an .xml file into a new Wordpress site is a breeze, and all content gets carried over and fed back into the new database in a matter of seconds. However, for both, the (archival) comfort was mostly in the idea that an entire database could be exported to a text file (very manageable), though the commands and content remain intermeshed (a lot of sorting required if you were to use that textfile as a manual or material backup). In these kinds of databases you find content and commands but no media assets (video and audio files are on a server somewhere) and no formal elements (no css or information about site design) though other CMS/databases (like TextPattern) do include site design (so if your database crashes, you lose everything).
While there are other ways to carry over (or aggregate) content from one database to another, such as Yahoo Pipes, cutting and pasting, and RSS Feed, I just wanted to conclude for now that backing up a database is simultaneously simple in action (press the 'export' button) and complex conceptually, when and if thought of in light of long term preservation...
Happy World Backup Day!
To be continued.
Update April 9: I Just saved my xml db to a word doc in 12 pt font and it is 8199 pages long.
