Navigation:  Random Thoughts >

ISAM vs. SQL by Steve Blank

Previous pageReturn to chapter overviewNext page

 

ISAM vs. SQL?

At the magicu-l group, there has been some long discussion over ISAM vs. SQL: is SQL better than Pervasive ISAM. And, as usual, Steve Blank had an unusually astute observation ... reprinted here with his permission.

 

Okay, here goes...

My thesis:

The real problem lies in the fact that it is just TOO EASY to write a working application with Magic/Btrieve.

My argument, stated allegorically:

Using Magic/Btrieve, any - and I do mean ANY - halfway intelligent person can  sit down at a PC and, in a matter of a few month's spare time (or less), crank  out an extremely complex, functioning application, without having had any real,  formal training in either application or database design, and then go out and  peddle it. Purely for ease of reference, let's give this hypothetical person an appropriately gender-neutral (and hopefully uncommon) name: Sydney.

Lacking proper training and having all of the complexities so elegantly abstracted by Magic, Syd quickly forms bad habits - hey, Syd started this thing having NO habits at all, and we all know that is far easier and more likely to form bad habits than good ones.

Syd sees everything as being either black or white: does it work, or does it not? If it works, great; move on to the next task. If it doesn't work, get out the shotgun and start squeezing off shots in the dark. Hmmph, that didn't work; don't bother to remove the useless code - doesn't hurt anything - just squeeze off another shot. Works! Great, what's next?

Finally, a product is ready for market. Sure, it's rife with crapola, but Syd doesn't know that; it works and what else is there? Syd remains blissfully unaware. Let's go sell it!

It starts small, with mom-and-pop shops - one user, one computer - works like a charm. Syd gains confidence and customers, adds features, expands his or her customer base, "upgrades" (exports and imports) the application to the next release of Magic, and so on until Syd eventually needs to hire some help.

Syd hires more Syds (they're cheaper), implicitly issues each of them a regulation shotgun and an infinite supply of shells, and cuts them loose to thrash about adding features and modifying behavior. Training? We don't need no stinking training - Magic's [too] easy.

Having no standards or supervision, each Syd does his or her own thing in his or her own way. Planning? Design? Waste of time. Inline comments? I wrote it - I'll remember it. Documentation? Later. Normalization? Huh?

Now jump ahead five years or so.

Due to Syd's energy and entrepreneurial spirit, Syd's customer base has grown to include more and larger customers; existing customers are growing, adding more employees and more concurrent users; existing databases are growing in size, and existing servers are getting long in the tooth; more Syds are added to the development team. Time marches on.

After years of anarchy, the application is a seething morass of dead, redundant, and flatly gluttonous spaghetti-code; shotgun-blast is the methodology of choice, if not now out of pure necessity; tables have hundreds of columns and tens of indexes; data redundancy is rampant. But, of course, the untrained Syd and his or her team of equally untrained Syds are and remain blissfully unaware and worse: entrenched.

Inevitably, inexorably, but ever so gradually, the Syds' myriad sins of the past, committed in ignorance, accrete and begin to achieve critical mass. One day, finally, the suffering masses' collective cacophony finally jolts Syd into awareness: performance sucks; people are constantly being thwarted by locking and other contention-related issues; files have grown from kilos to megas and even a few gigas, and file-corrupting meteors occasionally streak in from the heavens, laying waste to valuable data. It's always worked and still works at the smaller sites. What's going on?

Syd's conclusion: Pervasive simply isn't capable of doing the job.

Then, more or less later and in spite of the fact that Syd is equally ignorant of this thing called "SQL", Syd concludes that switching to "it" is the answer. This decision will never be visited again; indeed, nary a hint of it will ever again even enter Syd's mind to tickle his neurons, but rather be immediately and completely relegated to the annals of history, the dim and misty past.

But Syd is not without reverence for "it" and has heard enough of "it" to know that help is needed. Through either hiring or consulting or a combination of the two, Syd begins to grasp the extent of the unknown, and subsequently to draw the necessary expertise into the organization; the team of Syds finally receive direction, perhaps even formal training on habits and practices which, for some, will be the only formal direction and/or training they've ever had; all are subjected to baptism by fire; the database gets redesigned and subsequently mothered on an ongoing basis by someone who understands that "normal" has nothing to do with childhood development; large chunks of the application get rewritten; new servers get purchased.

Although not necessarily in the above order, all eventually occurs at a significant cost both in terms of time and money; but Syd and the team of Syds emerge from the ordeal as better managers and better programmers, having better skills, habits, and practices. And the application? It kicks ass and takes names.

Of course, that which had been lacking all along, often even since Day One, was a combination of some or all of expertise, training, good habits, best practices, planning, and design, all of which had always been acquirable (with equally positive results), but none of which had ever been force-fed to Syd and the Syds until "it" came along.

Oh yeah, and also of course, virtually no one sees this; virtually everyone agrees that "it" was the answer.

 

Steve Blank

 

DISCLAIMER: Although the foregoing is based entirely upon the author's own actual, real-life experience, any similarity to any actual person or persons, either living or dead, is purely coincidental.

:-)

 


Page url: http://www.magic-iug.com/MIUGWeb3/index.html?hm_isam_vs__sql_by_steve_blank.htm