Some thoughts about abstraction layers

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