On Apr 25, 2011, at 12:59 AM, Andrey Petrov wrote: > 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.)
I might actually do FooTag, BarTag, but each of those would have its own table alone (i.e. concrete table style). That way each object has a collection of "tags" thats entirely portable from the rest. Only if you need to query across "all tags" or otherwise correlate different types would I deal with an intermediary table. it depends on what kind of queries you want to do. > > (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. if the table is under a million rows and you're not on MySQL most differences would be negligible. The comparison of an index of (int, string) versus (int, int) comes into play as well. > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
