In regards to duplications, you might want to setup validations to prevent it entirely or at least limit it to cases with typos.
My ugliest case, I have writers with unique email addresses and each writer has many letters. Even with forcing email address to lower case, there are still typo cases and having to merge all the letters from one writer to another is a pain but it comes up often enough I wrote a small procedure to do it. On Nov 14, 3:22 pm, Peter Booth <[email protected]> wrote: > Sent from my iPhone > > On Nov 14, 2010, at 4:02 PM, Matt Jones <[email protected]> wrote: > > > > > On Nov 13, 2010, at 2:48 PM, Peter Booth wrote: > > >>> I see a couple of options: > > >>> 1) STI, aka Single Table Inheritance. This means that a single database > >>> table holds all the attributes for all of the different types of objects, > >>> and one column is used to hold the "type". This generally just means > >>> that some columns are unused in some objects. > >>> Seehttp://cookbook.hobocentral.net/recipes/23-using-single-table-inherit...for > >>> a recipe on how to use STI. (Note that there may be an issue using STI > >>> with Hobo on Ruby 1.9.2 -- Ruby 1.8.7 works.) > > >> I worked on an app that used STI for a model. This was a table whose size > >> was proportional to 100x number of registered users. So as the userbase > >> grew we had millions of rows that all include OneVeryLongCamelCaseClass > >> and AnotherVeryLongCamelCasedClass. I couldn't see why ActiveRevord didn't > >> use a numeric key instead of the classname. > > > The problem I could imagine with a numeric key is that it still needs to be > > mapped consistently to the correct class name, even in the face of > > adding/removing classes from the possible choices. The AR method has the > > advantage that a record's type can be readily determined when it's read > > from the DB, without reference to any other tables or configuration. > > That makes complete sense, but when I start seriously thinking "what if I > rename the classes A and B?" then I know I'm on shaky ground. I think it's > just that rails is an awesome framework for the common case, but special > cases will need some tweaking. > > > > >>> 2) rather than "has_many reviews", you can just use: > > >>> has_many :amazon_reviews > >>> has_many :yelp_reviews > >>> def reviews > >>> amazon_reviews+yelp_reviews > >>> end > > >>> then <collection:reviews> will automagically do the right thing and > >>> correctly display the correct card for each review. > > >> This looks like a winner for my use case. Thank you very much, Hobo is > >> increasing my enthusiasm for coding. > > > One note on this: this method will load *all* the objects in both > > associations, and won't work with pagination. In your application, that may > > not be a problem - but it's worth being aware of. > > I'm already having problems with table size, they are probably due yo me > being a server guy without much gui experience. For example: > > A Business has_many employees. > My edit business page will create a new employee without a problem. > > But if I inadvertently create two business objects that represent the same > thing, I might try to change the association on some employee objects from > business 2 to business 1. If I use the employee index page to navigate to > employee show, then my edit employee page has a select widget with upto 100 > possible business to choose from- no guarantee I can select the one I need. > > Pragmatically, what do you do when you want to manage associations with 1000s > or even 100,000s of records? > > > --Matt Jones > > > -- > > You received this message because you are subscribed to the Google Groups > > "Hobo Users" 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 > > athttp://groups.google.com/group/hobousers?hl=en. -- You received this message because you are subscribed to the Google Groups "Hobo Users" 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/hobousers?hl=en.
