On Feb 21, 8:22 pm, cult hero <[email protected]> wrote: > All right, I've been reading through the Advanced Associations portion > of the documentation and I came across this: > > "Polymorphic associations are really a design flaw. The only advantage > polymorphic associations offer is that they require fewer join > tables." > > I'm currently building an application that uses a polymorphic sort of > relationship because, frankly, I couldn't think of another way to > handle it. Having read what was said I began to wonder if I'm just > clueless or what. > > The application I am working in is a sort of research related CRM. I > want to be able to create multiple generic assets, subtype them and > then associate them. For example, let's say I have people, places, > events, books, images and movies. That's 6 different items. Right now > I have a generic "asset" table that has a many to many relationship > with itself and the link table provides a bunch of associations. I can > then go to any object and ask for all the assets related to it, > whether they be images or movies or whatever. > > Most of the time, you're working primarily within the context of one > type and therefore just the assets table and one subtype table. So, if > I'm working with events, I have an assets table and the asset_events > table. The asset_events table uses a Primary Foreign Key pointing back > to the base asset. That relationship is very clean and simple. > However, there are instances where I want to go the other way: I want > to start at the base asset and get the subclass. The problem is, it > could be a movie or an image or whatever and each type is in a > different table so I need a row that defines the type and tells the > asset table where to look for it's child. > > Now, I see this statement: "Proof by Reductio ad absurdum: If fewer > join tables are preferable, then surely fewer tables and columns are > preferrable, so you might as well store all of your data in a single > column in a single table if you think polymorphic associations are a > good idea." > > In this scenario, to create all the proper links if you wanted to > generically associate the objects, you'd need n^2 - n join tables and > all the messy code to spider through all of them. 10 different asset > types would yield 90 join tables, which seems a bit ridiculous. > > Is there another way to do this? Is there some technique I'm missing?
If you post your database schema, I could probably recommend something. If it is the case that you have 10 different types of objects that all object types can be associated to all other object types, then yes, you would have 90 join tables. That may sound crazy, but it is IMO the best way to model the situation, unless you are in the middle of a database table famine and have to conserve your tables. The join tables are easy to create, and they don't get in the way. You can easily get the the associated objects for any type by doing a simple many_to_many association and going object.association (e.g. people.events, books.movies, places.images, etc.). If for some reason you want all of those in the same array, it's not hard to create a method that concatenates all resulting arrays (book.events + books.movies + books.places, + ...). If you are using a polymorphic join table, the database is going to have to do the same number of queries, or risk creating large cartesian products if it tries to load all associated tables in one query if it uses a join. Jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-talk" 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/sequel-talk?hl=en -~----------~----~----~----~------~----~------~--~---
