Question of the day #3

What complex, high-volume transactional applications have actually been built in mid-range DBMS such as MySQL, PostgreSQL, FileMaker, or EnterpriseDB?

I’ve been flamed for suggesting that MySQL or FileMaker aren’t fully equal to Oracle and DB2 in supporting hard-core transactional applications. (Which is ironic, because I’ve also been flamed for suggesting hard-core transactional support isn’t as big a deal for DBMS selection as some relational purists insist. But I digress …) So I’m putting the question out there — what impressive transactional applications do the stand-alone mid-range DBMS actually support?

We can’t ask that question of the crippled editions of Oracle, DB2, et al.; it would be too hard to sort out from the apps running on their high-end versions. We needn’t ask the question of Progress and Intersystems; their reseller catalogs give the answer. We certainly needn’t ask it of MaxDB; it runs a significant fraction of the SAP user base. But for the four DBMS I named, I think it’s an interesting challenge.

Specific information I hope you’ll provide includes:

• Peak load of concurrent users.
• Peak load of transactions/second and/or updates/second.
• Metrics for the complexity of the database (e.g., number of tables).
• How intensely the application uses triggers, stored procedures, and/or declarative referential integrity.
• Any other metrics you think are impressive or relevant.

My logistical suggestions for supplying examples are as per Question of the day #1.

Edit: Fixed the link.

From a quick read, it seems all the tests were single-table queries, and some or all were designed to highlight the flaws of a specific design choice made in FileMaker (doing certain work itself when it would be more efficient to push it to the foreign DBMS).

*Mercifully, none of said insult-spewers seems to actually work at the company. I must confess that this makes it easier for me to take the (somewhat) high road here.

Possibly due to an actual understanding of enterprise technology, Tim Dietrich has weighed in on on the discussion from a different angle. Here’s a quote in which he gives an example of very successful FileMaker use:

Here’s an example of where FileMaker is a good fit — and where a traditional SQL database isn’t: A few weeks ago, I was given the task of developing a proof-of-concept for an electronic purchasing tool. This tool needed to be able to obtain real-time product information from a suppler that provides it’s data using Web services, allow the purchasing agent to make some decisions regarding what products they wish to purchase, and to submit the purchase order to the supplier as a cXML document. By the end of the first day I had submitted our first test order to the supplier (much to their surprise!). By the end of the second day, we had a full-featured application built. In other words, we went from specifications to proof-of-concept to production in a matter of days. (Try doing that in something other than FileMaker Pro.)

And you know what that is, ladies and gentlemen? That’s a story of composite application development. In composite application development, an app dev tool (not a DBMS) is used to quickly throw together an app by splicing together pre-exiting web services and building a simple UI. Notwithstanding that Dennis Moore has been talking about this over at SAP for years — and notwithstanding that every EAI (or alternative-buzzword data integration) vendor has some sort of a start on the technology — there aren’t any obvious, full-featured composite app dev tool leaders. If FileMaker can fill that role, more power to them.

And conceivably they might, because FileMaker’s two biggest limitations aren’t particularly relevant in that market. Team programming isn’t much of an issue in the classic composite app dev paradigm, and its DBMS weaknesses — well, actually, in this scenario FileMaker’s DBMS capabilities are barely relevant at all.

Technorati Tags: FileMaker, composite applications

In response to its small but vocal constituency, I got myself briefed on the FileMaker story. My conclusion, in a nutshell, is that FileMaker sometimes is a good alternative to low-end use of a standard relational DBMS. If you do feel able to use more standard-style products, you often should, for all sorts of obvious flexibility and future-proofing reasons. But if you can’t, or if you’re really confident the project won’t grow past a certain level, the FileMaker class of products can be a very appealing alternative.

Make no mistake; FileMaker is very different from conventional DBMS/app dev tool combos (and that’s the right comparison, as it combines aspects of both product categories into one). Indeed, the whole discussion is complicated by an unfortunate terminological confusion. Way back to the days of dBase and then Paradox, the “desktop” sense of “database software” was very different from the classic IT sense. What’s worse, these often weren’t really desktop products at all. That said, FileMaker fits into the desktop-database class of products, competing much more directly with Microsoft Access than with anything else. That is, it has selected application development and database management features, tightly bundled together, but falling far short of what is found in traditional DBMS or app dev tools.

How different is it? Well,

• There’s no true FileMaker language, just macros hooking together primitives called “scripts.” There’s no chance of a FileMaker syntax error as long as you stay within those bounds. But if you want capabilities not already available, you need to get somebody to write an ActiveX control for you.
• Not coincidentally, 80-85% of FileMaker users (company estimate) are non-programmers as their main jobs. And those are the more serious users. 1 million copies are sold per year; 13 million have been sold overall; and there’s no way even close to 15-20% of those are used by professional programmers. Right now the company has 2,000 paying members to its developer network, and aggressively hopes to up that to 10,000+ in a year. The company estimates there are several thousand professional FileMaker developers overall.
• There’s no separation between UI and data. Everything’s in the “layouts.” That includes integrity checks, business rules, and so on.
• FileMaker’s team programming capabilities are pretty nonexistent. The product is oriented to lone-wolf developers, although members of small groups can of course each work on separate parts of a large overall app.
• The average number of users of a FileMaker app is 14-15. 250 concurrent users is a hard (and somewhat artificial) limit.
• FileMaker is limited in its overall website building capabilities. Alpha5′s web site is, if I recall correctly, built in its own tool. FileMaker can’t do that.

Product futures include extending ODBC, Web, and general openness capabilities, and increasing the 250 user limit.

It also may be interesting to clarify a bit about the product’s history. FileMaker was developed outside Apple, then acquired into Apple’s Claris software subsidiary. Claris had 13-14 products at its peak, but FileMaker was spun into its own unit (still an Apple subsidiary). I’m not too clear on what happened to the rest of Claris. The product is fully pixel-for-pixel compatible between the Apple Macintosh and Microsoft Windows. And there’s been less total turmoil in FileMaker’s top management than one might think.

Well, there you have it. Does FileMaker fit among midrange OLTP DBMS? Not in my taxonomy. But is it useful technology? Evidently, quite so.

So should FileMaker be included on my list of midrange OLTP DBMS or not?