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 :-)).
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
Markus,
I like your approach, and I can definitely see the wisdom to having the
attributes inside these custom class definitions. It makes sense, and
the auto-complete feature is definitely one I would like to take
advantage of. I won't argue the point about the schema's permanence,
simply because everyone's shop is different, so I cannot possibly claim
that our case is universal. Definitely, I could see an intelligent ORM
implementation even throwing an exception if and when an attribute has
changed within the schema, thus pointing the developer directly to where
the problem is. I might even propose this to our lead programmer,
though he probably will not see a justification, as half of our
developers (i.e., 2 our of 4) use Textmate on Macs, while the other half
use Zend Studio on Windows - therefore, not everyone would really
benefit from the autocomplete feature.
I still see the benefit of being completely dynamic about generating the
permissible attributes, whether through a cached table structure of
otherwise. However, I might just look into implementing your own method
somewhere along the road.
Thanks for the suggestion!
