> > On Aug 21, 2011, at 6:57 AM, keyd...@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 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
