Re: DB Abstraction

Lukas Smith wrote: > I would disagree there. A query builder could do a lot > of stuff much nicer than a DB abstraction layer could > do. A query builder could make much better use of > RDBMS specific features than a DB abstraction layer > could. A query builder can build the query from > "scratch" with all given information whereas a DB > abstraction layer (unless it parses the actual > query) is fairly limited. For example think queries > that should work for relational and non relational > databases for example. This is what Apple Webobjects use: http://developer.apple.com/techpubs/webobjects/Reference/Javadoc/ This is how it looks like: http://developer.apple.com/techpubs/webobjects/GettingStartedOnWindows/Movies/index.html This is what Sun puts against Apple Webobjects: http://industry.java.sun.com/solutions/products/by_product/0,2348,all-873-99,00.html They even offer a transitional tool that converts Apple EOF into Sun ROF models. I once hacked together a quick study of a ER model representation and SQL generator in the days of PHP3. It was very slow due to object creation overhead: The ER model and access layer abstration use a great number of objects, most of which are only fired once or twice on a page. Using this to model abstract access to a database was not paying off within the deployment model of PHP. I stayed with DB_MySQL in PHPLIB and later ranted about the necessity of an Application server and truly persistent objects on this list. :-) Kristian