Joshua Olson wrote:
> For storing who-the-hell-knows-what properties for
> who-the-hell-knows different types of objects, I'd recommend putting energy
> into better defining the system's objects.
>Thanks Joshua
- normally I'd agree - but:
Consider the scenario I'm in: in negotiating with the end users of this
site, we can accept that they've categorically stated that they want to
be able to define the system's objects on the fly.
So what they want is a 'data layer' that can cope with all of these
different but semantically meaningful entities, so that while they may
need to write additional, ad-hoc bits of code to achieve their
higher-level goals, they nevertheless want to avoid, as far as possible,
building the data-storage logic from scratch. So for any particular
'system object', all they need do is create a template for that object,
and the same data layer can cope with all of these templates.
The data layer should give them an API which they use to store, retrieve
and filter this arbitrary data. The data layer should also give them
the powerful capability of all of these different entities being stored
in such a way that, as their archive grows, all of them can be collected
according to any arbitrary query.
I could easily say, well, phpMyAdmin gives you this power - good luck!
But my brief is specifically to write an API which absolves them of
knowledge of the database, and I'm interested in it as a paradigm
problem as much as anything else.
Am I insane even trying this?
Thanks again
Joe