Databases were one of the earliest applications for computers. Big Data requires databases. Your social media are all powered by databases. This blog is powered by a database, like most websites serving content on-demand.
Data exists everywhere, ready for you to search, sort, analyze, and print. Mail programs, contact managers, calendars, and many more of your desktop and mobile applications are databases.
There are several types of databases, including flat-file and relational models. A flat-file system resembles a spreadsheet. Data in the spreadsheet stands alone, generally, with no required relationships. Address books are flat-file systems.
Relational systems have interconnected tables. For example, a point-of-sale system must link customers to receipts and the receipts to individual inventory items. These relationships relate to each other. There might be dozens of tables in a relational database and designing such systems requires careful planning.
My wife and I use many databases regularly. We track recipes, books we own, and personal projects. For most of these tasks, we use single-purpose applications, such as MacGourmet and Bookends.
But, what about databases for our own uses? What about databases for which an existing application doesn’t exist or doesn’t quite meet our expectations?
There are choices for personal databases: FileMaker Pro, Microsoft Access, 4D (4th Dimension), Corel Paradox, dBase, Panorama, and a few others. There are ways to make a spreadsheet like Excel act like a true database, especially if the database doesn’t require complex relationships. And, for the more technically inclined, it is possible to use a server-based database, such as MySQL (MariaDB) or PostgreSQL. Then, there’s the big step of coding applications using a programming language and various libraries.
We use Apple computers and devices, so Windows-only solutions aren’t really what we want. This rules out Access, Paradox, and dBase for personal databases, leaving FileMaker Pro, 4D, and Panorama on macOS.
We have birdwatching lists in Excel and Word, exported from an ancient Access-based app that has been discontinued. My data had a FileMaker stop-over, too. I searched, and other than some ugly Windows, one Mac, and one Java solution, no bird observation software seems worth using.
A few years ago, tried playing with FileMaker as a solution, but FileMaker’s pricing is outrageous ($540 per computer) and coding a good merge routine wasn’t simple. We updated through FMP13, storing recipes, bird lists, other things, but the current version is FileMaker Pro 17 and there is no upgrade pricing from our old version.
Birdwatching data are relational. The IOC list is the main data source, updated twice a year by Cornell University. The master special data links to sightings, trips, and observers. Birdwatching is basically an inventory app, with GIS data for locations of bird species. I’ve diagrammed the table relationships over the years. Complications include species being split or joined over time as DNA data change taxonomies within ornithology.
My wife and I like organizing data. We like analyzing data, too.
What will I do for the birdwatching data? Will I splurge on an over-priced database tool that requires annual fees? Will I create a server-based solution? Or will I try to code a stand-alone application?
This is my database conundrum on the macOS. If FileMaker were more affordable, the answer would be obvious on the Mac platform. Since it isn’t affordable, I need to consider other options.