On 25/ott/06, at 12:33:08, Markus Wolff wrote:
Abu Hurayrah schrieb:
We got around this by actually caching the result of the SHOW
COLUMNS call per each request, and then simply checking for the
presence of this key (the table name) within the cache. If it
existed, we used the cached result. This boosted performance
significantly, such that, per page request, only /one/ call to the
table structure was needed for each table, no matter how many
records from that particular table were needed.
Hi,
I, too, have implemented my own ActiveRecord class. I don't do
*any* lookups at runtime, nor do I spend *any* time on cache
lookups. Instead, I let a script generate classes for each database
table, each class containing meta-information for the tables they
represent. All generated classes extend the ActiveRecord base
class. The generator script is run manually after each change to
the database schema - let's admit that the schema doesn't really
change that often (at least, it shouldn't :-)).
This is not necessarily true. In real word continued hacking of the
database schema is a concrete possibility.
It looks pretty evident there are two approaches which fit two
distinct situations. Most dynamic solution
(SHOW, DESCRIBE, all php code generated at runtime) is better suited
to development. Most static solution (no DB
access, all code in php files) is good for production. Then there are
many mixed solutions in between like caches, generators, etc...
which essentially start at one end and move more or less to the other.
I guess perfect solution is being able to take the preferred path and
change it at will, so i second a generator that can infer
all php code from database, that can be run on demand but can also
run just in time much like a cache.
Federico
