2007/4/9, Lester Caine <lester@xxxxxxxxxxx>:
Martin Alterisio wrote: > I have a dilemma on a design where I humbly ask your help. I'm working on > the model part of a web application (not to be understood in the "web2.0 " > way, but in a more general way, where anything mounted on HTTP is a web > application) done in PHP5 following the MVC design pattern. But the strong > point is that the result must be those-who-never-RTFM-proof. But that's not > my dilemma, I only mention this so that no RoR concept or similar is thrown > into the table, that is, NO ActiveRecord. > > The solution I presented is to access, and act upon, a database as if they > were PHP arrays, meaning that a table is presented as an array of records. > Here comes my dilemma. But first let me explain a bit about the scenario so > far: I snip there - too much detail without defining the problem ;)
Yeah, sorry about that, the concept seems a bit difficult to explain. I didn't found anything similar to point as reference. Database Data Abstraction normally refers to using a common internal
structure which can be loaded from a range of database engines. It sounds as if you have no requirement to 'Abstract' the database, only to come up with a persistent object layer under a single database engine?
Nope. It's an abstraction layer where the API is the common array operations, implemented through the SPL interfaces for that purpose. No explicit database is involved, except that some constrains to the structure of the data shall be involved. You have indicated that you are looking for a multi-user system, and so the
raw data must be in the database, but as you have seen, the flexibility afforded by any database engine is difficult to duplicate. The thing to remember is that you should ONLY be reading the data you need for the current user, and so your persistent objects do not need to be as complex as you seem to be looking for. It is always faster to ask the database for an answer than to copy everything to PHP in order to work with it. With any decent database you can provide views of the data in a suitable format for the arrays you need display on the user interface.
I completely understand, that's why from the beginning I decided that no precaching nor caching would be done, and lazy evaluation would be the way to go. The array operations would be transparently mapped to their counterpart db action when needed. I tried to find something suitable to point you at, but it's difficult
http://www.appelsiini.net/~tuupola/php/DB_DataContainer/ Is probably in line with your current outline?
Thanks but that's exactly what I don't want to do. --
Lester Caine - G8HFL ----------------------------- Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
Thanks for answering but my problem isn't how the abstraction will be actually implemented, but that the API (the array interface) stays as coherent as possible. If you have the time, please read what was snipped, those are my thoughts about how to make the array API coherent and what problems I encountered. Thanks again.
