Re: VLDB - for real?

Mark, Forgive me if I implied that VLDBs are not getting larger or for intimating that, as a bread-and-butter client we were less than happy with our Informix support. I am sure that database sizes will continue to expand outwards. My question is whether this future product is really the same animal as that which we were nursed on in the pre-history of 'Informer'. Silly question, of course it isn't. Still, that product had something in common with the current Online x.whatever in that the purpose of the database itself was to store data in a manner in which it could be inter-related and stored and retrieved along those lines. We had 'general_ledger' tables with links to accounts_payable and accounts_receivable and so forth. Perhaps not so suddenly the analysts claim that we are headed for the pedabytes. That is a heck of a lot of GL/AR/AP entries. The answer is that it isn't GL/AR/AP - it's images - of course I can base this only on Bill's and Jonathan's (C, not L) comments to date and my own warped perception. Since Online provides no means, that I know of, of relating data stored within the BLOB to anything else (every try to base a WHERE clause on a TEXT datatype?). It would appear as though what should emerge is not a larger RDBMS, but more efficient BLOB storage and retrieval - in short a VLIB or VLIDB if you prefer. I should leave the question of bread and butter support alone, but I can't. In the last several years Informix has adopted a much more aggressive marketing stance. This is laudable and is something the company had to do if it wasn't going to go the way of Visicalc. In the late 80's I watched Oracle chomp a larger and larger share of the perceivable client base with over-priced and buggy product - merely by using a VERY aggressive marketing strategy. I'm sure I speak for many of us when I say that Informix has historically been my choice for an RDBMS because it works. There is bound to be friction between trying to sell more agressively - which means more product - while trying to maintain the integrity of those same products and the goodwill of your customer base. Allow me to point at "4gl for windows" followed by NewEra and a few other tools - all geared towards getting a front end out there on the client. And what client? Why lets pick the platform with the highest user base - PC/Windows. This makes great sense from a marketing perspective, but there are relatively few complex products which work well in that environment. Clearly the decision cannot have come from a 'lets develop a quality windowing front end tool'. Recently the pricing structure of Informix products changed to a per-seat cost. Certainly this sounds fair and cheaper if you have a small shop. Unfortunately this is not the tone of the messages which came flying across this group. They were more along the lines of 'we got sexually exploited', to put it politely, from these very small shop clients. One of the reasons we are still running 5.0 is that although the upgrade cost is zip since we have a maintenance contract, the new maintenance cost is much higher - one way or the other we too are going to have to fork out some bucks. How different from the days when we purchased a product which worked well, albeit simply, which we didn't bother getting maintenance on because it wasn't complicated enough and which we then used at no further cost for the next decade or so. Obviously the company which provided that product is too good to last. We've now heard from two individuals that their projects are using multi-gigabyte if not terabyte databases. I am working on an information warehouse which is certainly going multi-gigabyte. I am sure there are others out there with these same requirements. I cannot question the need for an engine capable of handling very large databases, nor can I question the need for ever faster database engines. I can and do question whether the pedabyte database of tomorrow is going to be a true RDBMS or whether it is going to be a massive store of images, and if we are best served by our vendor of choice focusing overly at this end of the scale. cheers j. _____________________________________________________________________________ Jack Parker - Hewlett Packard, BSMC Boise, Idaho, USA jparker@hpbs3645.boi.hp.com _____________________________________________________________________________ "Chi va piano va sanno e lontano, perod chi dorme non prende pesce." - My apologies Julia for messing up your quote. _____________________________________________________________________________ Any opinions expressed herein are my own and not those of my employers. _____________________________________________________________________________