I'll confess to being a FileMaker fan if you'll admit to being a DB2 devotee. I think the big advantage of FileMaker is that it's friendly and approachable. You can treat it like an Excel spreadsheet (home to data in small businesses around the world) and get your data in without too much planning; and if that planning is insufficient you can update the database easily; and if you need another step there are the FileMaker developers who can take it over for you. I'd go so far as to call FileMaker cuddly - and you just can't say that of any other database!

OK, I'll admit to being a DB2 enthusiast - and if you want real scalability, run DB2 on a mainframe.

And, yes, Filemaker is cuddly. Its users love it, which must be worth something.

But I remember when a database called Dataease, with its own, non-standard, DQL query langauage (it would, very kindly, translate SQL into DQL), was billed as "user friendly". It was, up to a point. Then as your access requirements got more complivated, it fell off a cliff edge (you had to carry data around in hidden fields on screens because just knowing the key wasn't enough to find it again reliably). And if you networked it, performance died. I well remember ringing up about a query which didn't work as expected and hearing two support experts arguing about what a single line of DQL would actually do.

As Mark Whitehorn will point out in a piece on multivalued fields in Access we'll be publishing tomorrow, normalised relational datastores with management systems supporting a fairly close approximation to Ted Codd's rules are still around for a reason (for example, for large systems with tens of thousands of concurrent users). Even if I do think that reviewing Filemaker in those terms would be overkill - it has a server option and well-defined limits and within these (and since the file system rewrite) seems to work very well.