Upon actually inspecting a database created by SQLAlchemy, I find that you're totally correct, here. It's been long enough since I read the SQLAlchemy docs (somewhat more than two years, I guess) that I misremembered how it works, and I was confused by something I read in Hibernate's documentation a few weeks ago, so I came to a bad conclusion about how it functioned. Mea cupla. Thanks for explaining.hydr0x wrote:I'd argue that redundancies are always bad and should only be introduced if necessary(!). O/R-Mappers have to have a concept of direction as objects do have them. They are forced to map this to the database. But, as far as I can tell from the SQLAlchemy documentation, adding backref or not to a m:n-Relation does not change anything on the database end. It certainly doesn't seem to add the redundant column in one of the data tables, but rather just creates a relation table. All backref does is add collection objects to both data classes.
Indeed, there's no need to worry about minute details of implementation at this stage. When I started this thread I just wanted to suggest using a generic format for game relations (as opposed to something like a 'sequel' property on each game) but it somehow turned into something very different.hydr0x wrote:Anyways, it's pretty pointless to discuss this. A) the guys aren't yet in the implementation phase B) hibernate will force it's own idea of database design down your throat
As for the Hibernate best practice, it's questioned by quite a few devs, see this discussion for an example.
Thanks for the link to that discussion. I think the particular situation in that answer ("one-to-very-many" and "many-to-very-many" relationships) probably will not happen for us, but it looks like that's not the only time Hibernate can have performance issues. I've learned some useful things, tonight!