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 :-)).
Another solution besides running the script by hand would be to abstract
its functionality out into a generator class that can be temporarily
activated when in a development environment, where speed doesn't matter.
The classes could then, too, be regenerated on every request. So far, I
haven't had any need for that, though.
IMHO, this is the most efficient way to handle ORM - other well-known
implementations, like Propel or DB_DataObject, seem to agree with me.
Also, due to having each table column as a hard-coded class property, it
enables code-completion in IDEs like Zend Studio or PHPEclipse, which
can boost developer productivity.
CU
Markus
