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 definitely sounds like the most useful solution. But it could even be a combined solution, where the extending classes can optionally contain the meta information. If they do, the meta information is used, if they don't, then a lookup will be done in the database (and this may or may not be cached either). Such a combined approach would be very flexible and would cater to the needs and preferences of all developers.
I could for instance see that having the mapping absent might be useful in the development stage, where the schema might change every day to accomodate new requests from the business. And then, just before the system is put into production, the extending classes are replaced by generated classes with meta information, so that the production environment won't suffer the performance loss. I can't think of a more flexible way to do this.
--
Stefan Koopmanschap
http://www.stefankoopmanschap.nl/
http://www.leftontheweb.com/
