Hi Matthias & Ryan & all,
> > > Sigrid, this sounds like a context-dependency. That is, you use the same > language (in the sense of API) but depending on the DB to which you bind the > meaning is subtly different with implications for correctness and > performance. > > I am wondering whether a unit-oriented approach would help here. You could > write your program against a uniform API that adapts itself properly to the > DB context in which it is deployed. Originally, I just wanted to make the point that when an application is migrated to use another rdbms, serious work is - that is, should be - involved to assure the query results still are as expected, and the performance still is OK. This would primarily mean carefully checking, and possibly changing, the sql, but also more global "database access behavior" like e.g. commit frequency, or whether in order to perform concurrent queries, you open several or just one connection to the database, etc. In no way did I mean to suggest that it wouldn't be desirable to have some kind of wrapper around the different database drivers, making the codebase look more uniform, or (@Grant) say anything against using the Data Access Object pattern - only this should not lead developers to think that it does not matter which database their code runs against, and everything will be taken care of by the driver. Well so in fact I was thinking, perhaps my comment really was not to the point, the topic being about some wrapper code only, I should not have written what I did :-; But now with your comment Ryan, > > There are many things you might mean by that (ORMs, > relational-algebra-to-SQL compilers, etc). The concerns that Sigrid > raised make me think that hiding *all* the differences is a hopeless > task, but maybe something with a narrower focus could be useful. Are > there any existing frameworks that accomplish what you have in mind? , I start to think I was not too far off perhaps? Because ORMs, and relational-algebra-to-SQL compilers (one thing I find fascinating personally, but ...) would be fine examples of software that'd run into the kind of problems I was talking about. One popular (in every respect) example in the Java world would be Hibernate, as not only does its code generation not take into account the specific characteristic of the underlying rdbms, but additionally, by its convenience of use, it creates the illusion, in a way, that treating the DB as a "black box" will bring no disadvantage (or even, is a good thing). Ciao, Sigrid _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
