database independence

We are in the planning stages for development of a brand new product. This product will be Unix based and will use A database as a data store. One of the questions we are grappling with is whether or not we want to attempt to be "database independent". By "database independent" we mean supporting a limited number of rdbms vendor's products such as Ingres, Informix, Oracle and Sybase. Since many of our customers may already have a database of choice, it would be nice if we could simply cut an Oracle version of the product or a Sybase version of the produt from the same loadline.

My question is "What type of issues would be involved to acheive this level of independence?". It is my understanding that the ANSI SQL standard sets specific guidelines for embedded SQL. It is also my impression that most vendors attempt to conform to this standard, adding their own extensions of course. Is it then reasonable to assume, at least in the case of embedded SQL, that such "independence" could be acheived with minimal difficultly? I could envision some syntatical differences between the implementations that would require an occassional #ifdef, but I would hope that the majority of the statements could be reused.

In terms of the database itself, I am assuming that if we use the lowest common demonitor of the SQL-92 standard which is implemented by all vendors, then the schema would be fairly portable as well. Again, it may be reasonable to have product specific schemas which take advantage of a particularly useful feature or conversely accounts for some anomoly or divergence from the standard.

So tell me...have I been sniffing too much model airplane glue?!?! I know there has to be more to it than what I have outlined above. What am I overlooking? I would love to hear from anyone on this subject, especially if you have tackled this "independence" issue yourself.

							John Vasicek
							jsv_at_tellabs.com