[racket] db independence [was: something else]

> 
> On Aug 21, 2011, at 6:57 AM, keydana at gmx.de wrote:
> 
>> Perhaps I can add a remark to this "from the other" (the database admins') side :-; ? From the point of view of an Oracle DBA (I'm emphasizing "Oracle" here as I don't want to generalize, having no comparable experience with other rdbms's), applications written with a goal of "database independence" can be a big problem and lead to grave performance (or even, data integrity) issues. This is because even though the sql may be the same, important concepts like read consistency etc. are implemented in a very different ways in different rdbms'.
>> So anyway, when an application changes to use another rdbms, major work might be required  ...
> 


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. 

Warning: I have no clue about real databases. This may be complete nonsense. 

-- Matthias