Re: database independence (repost)

Yeah, yeah ... I'll get this editor figured out. Here's the article WITH CR's!!

The problem with programming down to the lowest common denominator is that you get the lowest common denominator. Different databases have more advantageous ways to do different things. Database independence is important, as is hardware independence. My advice is to separate all of your database calls through a couple of layers of abstraction. Then, your F/E simply calls a function and gets data back. This should de-couple the database relationship. By using two layers of abstraction, you can get some additional scalability and independence (e.g. you can use a distributed architecture or a monolith architecture).

Good Luck,

 Topher

---
Christopher A. White          | "I once could see, 
McCaw Cellular Communications |      but now, at last, I'm blind."
Kirkland, Wa                  |         -- Dream Theatre