For many years I was the database expert in our department at Motorola. I fell in love with SQL (Structured Query Language), and although I never had the home budget for my own copy of Oracle, I made do, first with shql which made a valiant effort at making an SQL compatible database out of shell scripts and text files. Of course I later moved everything over to the free Mysql. I still have my writing and submission database running there, with a home-brew perl cgi interface. But as I began actively becoming a publisher, there was new data I had to track, like inventory and bookstore visits and such. When Apple came out with their new consumer-level database, Bento, I wanted to give it a whirl. The advertising seemed to hint at relational abilities, maybe I could move to a turn-key consumer product and not have to spend my vanishing time coding up a new web front-end to yet another mysql database.
Okay, starting simple. It’s dead easy to put together a plain table with a handful of nice data types like text and currency and date and even media. You can easily make spreadsheet-like tables and nice forms with any subset of the data you want. This was particularly nice for Mary Ann’s table of photos since it let her put thumbnails of the photo right there on the page so she didn’t have to remember just which owl picture was which. (Believe me, she has many owl pictures!) However, there is something I should warn you about. I was thinking the images were converted to thumbnails when you drag the photo file onto the form. No. It stores the whole image file. That’s great for some usages, but some of Mary Ann’s tiff files are 100+ megabytes. Her Bento database was quickly 3 GB and I had to go back and convert them all to thumbnails manually (with a little help from Automator).
It’s when you want to connect two or more tables that things get wonky. There are no table joins, or the like. As far as I can see, the only thing you can do is put a little baby table image of the related table into a form for the other. Click on the image to see it full size. In this example, I have a bookstore list, which is actually from my address book, as a “Related Records List” field type. It’s like the form does the linking. I’m sure there is actual database table somewhere invisible in the background that handles all the grunt work, but the consumer isn’t supposed to see them. Also, you can easily do “many-to-many” linkages through these forms, and the little related record views are fully editable. That makes it easy to Mary Ann to add all the data for a photo submission from just one form view, rather than switching back and forth between forms for different tables.
I can actually understand the design choice there. In SQL join, if I had two bookstores connected to two book titles, it would return four records in the table. That might just freak out the consumer-level database user. The problem is my mind has been grown into one database model, and I have trouble accepting this alternate way of doing things.