Thank you vERY much, Chris! -- One often has moments where he/she notices something that may or may not be a real worry, but is too doubtful to speak of it. I have each of your described considerations pulsing through my head each time I think of the future of how these models will be in case of modification or deletion, but it was too vague as I had no substance to fill even a hypothetical example. But your spelling them out certainly relieved me a little.
Having been thinking of these (potential) problems, it compelled me to think whether there's a kind of tutorial I can read up on some rules of thumb of deciding if table or no table and so on. I thought, a few days, ago, that in the worst case, if I made each column its own table, a Phone Model, a Gender Model, an Areacode Model, etc, basically every thing would have its own model, though unrealistically complex, it'd work ( sort of conveying that the more orthogonal bases you have, the better; in Linear Algebra). So building up a network of tables each holding exactly one column, I was thinking that, some empirical/theory-based rules for combining these hypothetical single column tables. And your Socratic method (I hope I am using this phrase right) isn't bad, at all. I will discuss with my supervisor for possible scenarios that call for minor/major table alterations, then I will begin to ask these questions myself :) Thanks again! Thank you, everyone! On Apr 14, 11:16 am, Chris Bird <seabir...@gmail.com> wrote: > This is a specific case of a more general problem - how to manage > inheritance in these kinds of models. There are several things to > think about here. However they break down fairly easily. I'll use your > specific example, but some of the observations might not make a whole > lot of sense. So I will pose some questions and then give some guiding > thinking. This will not be RAILS specific thinking, but bringing > experience from enterprise class systems where we have things like > this all the time. You can generalize the thinking questioning when > the structures are even deeper. > > Which attributes are common between Clients/Contractors? > - If there are a lot of attributes in common you might get away with a > single table, and a type field in the table. > > Are there relationships identified that both Clients and Contractors > can have? > - If for example you had a security tag table and it needed to have > the associated "person", and it doesn't matter if the person is a > client or a contractor, then it might be worth managing that > relationship via a separate table (a Person table). > > Do you expect to add new kinds of things? > - Are Clients and Contractors the only types of Persons? Will you need > to add something else in the future - e.g. Overseas Contractor which > is like a Contractor but has a bunch more fields, its own processes, > screens, etc. If so you may want to break into multiple tables. > > Do you expect to have a role concept that cuts across Clients/ > Contractors? > - Similar to relationships above, but let's imagine you also have > roles like administrator, user, ... If those roles are independent of > the Client/Contractor status, then again you might want separate > tables. > > Do you have to worry about history/transition? > - If a Client can become a Contractor (or vice versa) - and you need > to manage the history (for example if all the timesheets haven't been > cleared yet), then you will have to have something a bit more complex. > Now you have to manage the temporal element when the Person can be > both. There are lots of ways of doing that, none of them ideal! > > If you do decide to break into multiple tables, then make sure you > manage the relationship handling among the tables inside the Model. Do > not be tempted to put this into the Controller(s). Then you can treat > the join of the Person with the Client or the Person with the > Contractor as if they were individual Active Records. There will be > performance penalties, but performance while important is not the only > consideration. > > Hope this helps > > Chris > > On Apr 10, 5:42 pm, Nik <niks...@gmail.com> wrote: > > > Hello All, > > > I have a User Model at the moment that has only username, password, > > and roles. As you might guess, I can add to the User Model a phone > > column which our clients have and our contractors also have. Many > > other attributes may be share by both actually. But then only a client > > can have a "rate" column, and a company association and other things. > > And only a contractor can have, say, an internal FTP login/password > > pair. > > > I don't quite know the nature of rules on deciding just how I should > > do about these un-shared attributes, I know that I use the "roles" > > column to differentiate a client and a contractor (learned from Raile > > Recipes); should I pool all attribute into User Model anyway and then > > find a mechanism to permit/forbid a client to see the contractor only > > attrib and vice versa? or two other tables one being > > contractor_only_properties and the other client_only_properties? I > > feel that having to build a table for each role seems a bit, I am very > > unlikely to be right, inflexible or at least un-easily-extensible > > (sorry for making words like this). > > > Your (any) opinion is very valuable to me and I thank you for spending > > your time reading my problem > > > All my best, > > Nik --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
