It's equally true to say that a spreadsheet program is a specialized form of a database management system (DBMS) and a DBMS is a monstrously upsized spreadsheet program. But a lot of people think that there is a great deal of conceptual difference between the two. Current implementations don't try to bridge the gap very much but it doesn't have to be that way.
One of my older clients came to me with a problem that brought this to light today (He's a consultant too but he uses me as a technical backstop on occasion). He was getting multiple data sets from various sources. Singly, they would fit in Microsoft Excel but all rolled in together it would be an uncomfortably large dataset and ungainly spreadsheet that would need to be manipulated by too many people simultaneously.
His problem was that he was much more comfortable in a spreadsheet mindset than in a database mindset, even though he knew that a database was a better solution for his client. After a phone call, it was all straightened out and he's off to implement a workable solution (he'd already had it 7/8ths of the way even without me).
What occurred to me was that one of two things would have eliminated the need for the phone call. If Excel had a better data store, it could scale up and have handled this problem. Likewise, if Oracle, MySQL, or even MS SQL had a front end that acted like Excel, that would work too.
The number of application programmers who would benefit from either tool is quite large. There are a lot of people who live in their little corner of the programming world. The problem is that Microsoft, the dominant spreadsheet vendor that could most easily solve this problem is also the least likely company to engineer such a solution because it would cannibalize sales for Excel, Access, or MS-SQL, perhaps even a little bit of all three. There's no commercial imperative to do it.
Nobody else seems to have thought of entering that niche.
Pity.
Posted by TMLutas at January 2, 2004 09:03 PM