Fog Creek Software
Discussion Board




User Database Selection

I believe a while back Joel mentioned that FogBugz was updated to support MySQL as well as SQL (and possibly Jet).  I know Movabletype, a piece of blogging software, supports the BerkleyDB and MySQL.  I've seen a bit of discussion lately about Jet vs MSDE.  I'm curious...  How good of an idea is it to give the end user the ability to pick and choose their SQL Engine?

Granted, In a situation where the user says, "We use SQL engine X, so you need to build the application for it" you do that.  However, when creating a piece of software that's going to be sold or downloaded by random people, is it a boon to support multiple SQL engines/databases?

Any opinions are welcome and appreciated.

Andrew Burton
Wednesday, May 21, 2003

While I'm referring primarily to open source software here, there's been multiple times I've rolled my own or chosen an alternative because I didn't want to run the only DBMS supported by the software.

I realize it's significantly more difficult to develope for N different DBMS's, but if you can do it, I think it's worth it. Of course, that assumes that that's a big enough problem for your market: ideally, it's a good idea, but not if you wouldn't grab enough extra sales to warrant the trouble.

Mike Swieton
Wednesday, May 21, 2003

I used to work for a company that sold a product that worked with Oracle, Sybase, Ingres, Informix, Progress, MS SQL Server and in a limited version paradox. In some cases it could use more than one connection method to database (like ODBC or vendor's interface or third party interface)

It also worked (required as well not instead) with more than one text retrieval engine

You'd be surprised just how much work it was.

With simple use, and not too many records, it was easy

But with big databases or complex applications it was tough. Plus obscure bugs came out regularly, and performance issues.

You do A,B,C in database X, works fine.  Do same in database Y, the client takes 30 minutes to wake up.

S. Tanna
Wednesday, May 21, 2003

It is easy enough to write code to handle multiple database servers, as long as you restrict yourself to using only those features that all the target database servers support.

Your customers probably expect your product to work, and this means that you have to test against the various database servers. You also have to support database servers as new versions of the server come out. You can support the current versions of N database servers today, but in a few years you may find yourself supporting customers running M different versions of each of the N database servers. This N*M problem becomes impractical, unless the product pricing is such that you can essentially treat each sale as a custom system.

We have found the testing and support problem to be overwhelming if our support is too broad.

Dan Brown
Wednesday, May 21, 2003

Thanks everyone.  That's given me some goot things to chew on.  I appreciate it!

Andrew Burton
Thursday, May 22, 2003

> But with big databases or complex applications it was
> tough. Plus obscure bugs came out regularly, and
> performance issues.

Same thing here, although my context is somewhat different - not having to support several DBMSs simultaneously, but having to port between two such besats.

Some 4 years ago, someone decided it would be a good idea to switch our standard DBMS.

We've had a lot of problems, especially with our web apps. One of the apps, that allows our customers to check their movements online, had 2 DBs, one in each DBMS, because of the bugs in the driver.

Fortunately, we ended up not switching completely. I say "fortunately", because I was lucky enough to end up in a pretty homogeneous (sp?) setup. I imagine some of my coworkers may have a different opinion :)

--
"Suravye ninto manshima taishite (Peace favor your sword)" (Shienaran salute)
"Life is a dream from which we all must wake before we can dream again" (Amys, Aiel Wise One)

Paulo Caetano
Thursday, May 22, 2003

*  Recent Topics

*  Fog Creek Home