|
The chance to write a relational database drew Jim to DEC in the mid-seventies, but the prevailing wisdom said that only network databases could support commercial applications. That misconception took four years to dispel, during which Jim designed and wrote Datatrieve, a relational query language that ran on flat files and DBMS-32. Datatrieve users wanted more flexibility, better concurrency control, and atomic transactions.
When DEC finally embraced relational technology, Jim was still in charge of Datatrieve, so another group began designing what became Rdb. They debated the meaning of "relational" and the meaning of "database." They scoured the literature and held wonderful discussions about degrees of consistency and predicate locking and shadowing techniques. But they didn't start coding.
Shadowing in the Shower
Jim got impatient, and began playing with shadowing, which he saw as a way to provide a repeatable read without blocking updates. Then, one morning in the shower, he realized that the shadows could be also prevent update conflicts and undo failed transactions. The multi-generational database revealed itself in that shower.
Intrigued, Jim began serious work on the database called jrd. DEC's management discovered that it had two relational database projects, the real one and jrd. The database wars broke out.
Those were dark years, full of internecine politics and flaming email. Jim, Don DePalma, and I decided there had to be a better way. We learned that Apollo Computer, a local workstation company, wanted a private-label database. Apollo's management liked the jrd model, so Jim moved into the second-floor spare room and started coding. The initial capitalization was $243.50 for a comfortable chair and two filing cabinets to hold up the door that served as a desk.
When Apollo contract was signed, eight months after we started negotiations, money started to flow in. Don and I joined Jim in the very very hot second-floor spare room. Jim coded; Don wrote the manuals; and I did some of everything. The cats slept on the computers, sprinkling cat hair and dander all through the machines. Apollo field service came by weekly to vacuum.
Dave Root left Apollo and became the fourth founder. Every company should include one sane adult. The four of us overflowed the spare room, so the company spilled out onto the balcony.
Then we began to have customers and potential customers, and meetings and mailings. The guestroom became the copy center and mailroom. The living room was for conferences. We all cooked in the kitchen and ate in the dining room. The coffeepot sat beside my sink in the master bath. We weren't working at home anymore, we were living at work.
That winter, the driveway was a luge run for Saabs, icy, twisty, and lined with trees. Our first non-Apollo customer arrived from Santa Barbara California in February and slid into the front yard, barely upright. He signed the contract anyway.
Groton Database Systems moved out of the house and into an office over a dry cleaner. I got my bathroom back.
"Groton Database Systems" is an inspired name, inspired by our failure to find any other name that passed trademark search. We were naive new entrepreneurs, so each time we thought of a name, we asked our lawyer "is this OK?" Later we learned that the right question is "can you defend us if we use this?" That sophistication let us change the name to InterBase, a change encouraged by the person who answered the phone "Rrrrotten Database Systems."
Concept: Simplicity
What were we trying to do? Build a relational database that didn't get in the way. One that was simple to install, required little or no administration, and would work inside applications.
We all had experience with network databases: IDMS, Seed, DBMS-32. To use a network database, you really had to love tuning, tweaking, studying, and fondling your database. InterBase was for the rest of us, who want to get on with our real jobs.
The multi-generational architecture - Jim's shadowing Eureka - eliminated problems that other databases stumbled over. A reader could create a large, consistent report while others continued to update the same data. Transaction rollback was simple; even crash recovery was automatic.
Next column
|
