Follow the Yellow Brick Road

An update on where I think this SSD/multi-machine/BCNF database journey is going. The independent storage vendors are adopting a "tiered storage" paradigm, with SSD/HDD machines and embedded controllers aimed at "enterprise" clients; large servers (quasi mainframes) and mainframes. My conclusion is that their clients don't want to refactor anything, just keep that 30 or 40 year old code and make it run a bit faster. Such machines adopt a disk caching approach; I'm not convinced that there is much point to having live data on multiple varieties of persistent storage. (Aside: in the *nix world of databases, it is understood that the database machine should have *nix file buffering turned off so that the database can do it's thing, faster. The same applies to persistent storage. They'll all find out, eventually.) So, who's going to adopt SSD/BCNF machines outright?

Well, back in the late 1980's, the VAR (value added reseller) emerged as a conduit for *nix database companies. The archetypes were Progress, Uniface, and Informix (PowerBuilder in the M$ world). They provided a "relational" database and a 4GL to manage it. In the case of Informix, it was/is a real database with proper SQL access. The others stressed their own 4GL over SQL. They aimed at developers with business expertise to build replacement applications for hoary minicomputer (mostly; some mainframe) file based ones. Since these folks weren't burdoned with legacy "stuff", they had a reasonably clean sheet.

This venue is where I see the entrepreneurial force to accept the "new" idea of declarative data, minimal code. The VARs I've dealt with (or worked for) always supplied the machine, too. A source of profit, but also met a strategic need: support of clients is *so* much easier if you already know more about the full system than the clients. Shipping out the full system with a couple of STEC drives (or Fusion-io, or...) is not a client decision. That, fact is, has always been true. I still keep getting calls to work on COBOL code that's decades old, when it is clear that such organizations are desperately trying to keep from sinking in the tar pits (like the metaphor?), without having to do any real thinking or engineering. The other area is a gawd awful lot of SQLServer. I don't get that at all. Not all change embodies progress, but all progress requires change. You can't make an omelet with breaking some eggs. Doing the same thing over and over again, and expecting a different result, is a definition of insanity. The first step in fixing a problem is to admit that the problem exists.

Now, I just have to find one. And, no, I don't have in mind any application that I just have to create; I care about the tech, not the application.