It depends on how you develop you application. A good design will be able to take that in stride with only changes in the application data layer. By using adapters and factory classes you can simply keep a small stock of them for each implementation. Need to add MySQL - its not a problem, just complete the adapter for that database.
My current app can roll out using either Oracle, SQL Server, or MySQL - it can use IIS or Apache as the GUI. It is database independent because the part that interfaces with the database is designed to be flexible enough to absorb changes without affecting the outside world. We have tested with SQL and MySQL and a customer took the application cold and it now works in Oracle. Chip On 9/14/05, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: > > From: "Chip Dunning" <[EMAIL PROTECTED]> > > > I do not understand why so many thing database independence > > is a fallacy? > > Well, there are at least two separate scenarios here: > > 1. The WhizBang(TM) product or project originally used Oracle but must now > use SQL Server instead. > 2. The WhizBang(TM) product originally used Oracle but must now also > support > SQL Server. > > It's the second case that's problematic. From the perspective of > maintaining code, testing, documenting and providing support, you really > do > have two products and not one. > > -- > Curt Hagenlocher > [EMAIL PROTECTED] > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > -- "The reason the mainstream is considered a stream is because it's so shallow" --George Carlin =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
