Re: Some thoughts about abstraction layers

Hi Alexander, What you are proposing is very tough to implement well (eg. scalable and portable). The main problem is that database vendors have no interest in portability, accept to make you switch to their databases. So you actually have to fight against their clever incompatibilities to create the ultimate portable container. Secondly, every vendor approaches scalability and performance differently. For small apps, whether you use a database wrapper or direct database calls is irrelevant. For large apps, you have to use vendor specific SQL calls at times to scale. See http://wdvl.internet.com/Authoring/DB/Oracle/OneonOne/oracle1-2.html for some horror stories when developers ignore the database internals. Regards, John Alexander Merz <alexander.merz@s1999.tu-chemnitz.de> wrote in message news:018d01c178ef$d7e96a80$0200a8c0@alex... > We had a heavy dicussion DB abstractions layer in PEAR last days. Especially > about introducing Metabase in PEAR. > > But before discussing real implementation, we should stop and thinking about > what we want and what we need. > > 1. The starting point is: We want to retrieve and store "information". This > could be addresses, articles of a shop or your cd-collection. The type of > information is application specific and can't be really generalized. In an > OO-speak, you would call it just an "object". > > 2. So now, the information have to be stored somewhere. Let's call such a place > "information container". We store the "information-object" in an > "information-container". The container is responsible for storing and retriving > the information-object. > > 3. The information container could be a R-DBMS, a OO-DBMS, a file, a LDAP or a > punch card. This systems are special "data containers". The information has to > be divided into data ( address => street, postal code, town, etc) and insert or > read the data depending of the kind of data container, because of the different > ways of accessing the special data container. I.e. for R-DBMS this could be > SQL. > > 4. But there is often not only one R-DBMS or one kind of storing data in a > file. So it make sense to have a special access API for every kind of data > container, i.e. a SQL-API for R-DBMS. The API can handle different > implementations of the SQL-Standard in DB-programs ("physical container"). > > 5. The physical container is program/API that will be called at the end, i.e. > for R-DBMS MySQL, Oracle or MSSQL. But unfortunatly the the API or program > parameters differs, not only between the data containers, always between the > physical container too. So we need a unified API for every data container. > > +----------------------------------------------+ > | Informationobjects | > +----------------stored in---------------------+ > | Informationcontainer | > +---------------which could be-----------------+ > | Datacontainers like | > | RDBMS |OODBMS|LDAP|File| > +------access data by---------+......+....+....+ > | SQL | API-Calls| > +-------from-------+---on-----+ > | physical container | > +--------------like-----------+ > |MySQL|ORACLE|MSSQL|..........| > +-----+------+-----+----------+ > > So whats a real abstraction layer? This abstraction layer have to represents > all this kinds of layers! A db layer has to abstract the RDBMS and(!) OODBMS > data container with all underlying layers! A lot of work... > > PEAR::DB realize the physical container layer with accessing Data by SQL, > Metabase tries to cover the data container layer + underlying but Metabase > defines data container as a kind of SQL-RDBMS (it swapp the data access layer > and the data container layer) > > Ok, this all is a little bit confusing and very theroretical, but keep this > stuff in mind when you talking abstraction layers > > Cu, Alex >