So if I understand correctly, You would choose the (1) assoc_id/type secondary table approach that you outline in the blog post over having (2) redundant schema per-table with direct FKs (FooTag, BarTag, etc)? Why? (I have a feeling I'm misparsing what you're saying.)
(1) worries me because I would need approximately one extra row in the secondary table per row in other tables, plus the extra join. I'd need to test this but I imagine the performance implications would be significant. With (2) I get more tables, but at least it's a reasonably compact and simple representation. I do agree that the hackish rails-style association is not ideal. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
