I won't argue with the difference between an ORM or a DAL, but just for the
sake of discussion for future references, I'll tackle this from another
angle......
We (I'll include myself in the group) that work on databases daily have a
bad attitude towards super-normalizing things that maybe don't need
normalization at all. That being said, I'm well aware of SQL syntax to
retrieve what I want and DAL seems more natural because it feels more
"controlled" (i.e. I know what it is doing under the hood).
as long as all "Amtrack" trains doesn't need to become "Amtrack2" on future
day, references are just a bad way to deal with your model and your
queries.....
A train with a company referenced in another table by an id is a train that
can (should) switch companies often, even better, is part of a group of
trains that* somewhat needs* to change company often. That model allows you
to change a single "Amtrack" record to "Amtrack2" and have all the trains
"belonging" to "Amtrack" to be "Amtrack2". If that' not the case, why don't
you simply use
Field('company', requires=IS_IN_DB(db, 'company.name'))
?
That way you can issue queries like db.trains.company == 'amtrack' that are
- usually - faster than filtering records through joins.
--
