My replies are interspersed with Stuart's note. Rhino
----- Original Message ----- From: "Stuart Felenstein" <[EMAIL PROTECTED]> To: "Rhino" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "Stuart Felenstein" <[EMAIL PROTECTED]> Sent: Saturday, August 28, 2004 6:08 PM Subject: Re: Many to Many: Does this make sense ? > Okay, hopefully I'm somewhat clearer today. I doubt > it but the effort is going to be made regardless. > > First off, Rhino I read through your last post, > regarding the phone number table. Yes I defintely > understand it and see how each situation may warrant a > different design. You gave scenarios for both. Very > clear. Slowly it's sinking in. For example, I had a > "states" table, but I was going to accept Cities to be > text input. Very wrong. I came up with a very solid > list of major cities in ever state. So far so good.... > For redundancy > I'll probably add metro areas, and quadrants of some > sort. Each of course with their own tables. I see > this is as a very good place to implement the M2M. > Agreed ? > Sorry, I don't see what you mean here at all, particularly what you mean by a quadrant in this context. Are you talking about deciding whether Cleveland is in the Northeast or Northwest? If so, what do you care? Or does it support some aspect of your business where you have to know which region the customer is in? It is very hard to assess a database design that is paraphrased in a few sentences. There is a great deal of potential for misunderstanding what you mean that way. You have a far better chance of communicating your design clearly if you supply table layouts of the kind Shawn and I put in our notes on this topic. > Now, back to my title list. There are a number of > business reasons why I'm forgoing the title table and > even tracking titles in a seperate place. After > looking through Monster and CareerBuilders and the > similar others, there just isn't enough proof that it > would make sense. Some of the titles I've seen are > combinations of things totally unrelated, others are > comppletely vauge. While there are standards and > atypical job titles, there are also a huge number that > are not. For instance, I applied for a position a few > months back titled, Senior Sales Representative 12. I > thought I was an eleven, so I went for it anyone. All > reasoning aside. Seriously though, I just believe > after review that it makes no business sense for that > design. If I was running an internal job site for 1 > company, then yes perhaps. There is a table though of > industries and fields. > > Hope this explains my mutterings the other day. > Actually, I'm probably just more confused. You have to understand that I don't know what business you're in nor do I know what your system is trying to do. You have actually caused some of this confusion by "shifting the ground" with your examples. One minute, we're talking about dogs, then it turns out that dogs were just for the purpose of your example and that you're really dealing with colors. Only then it seems that what you *really* meant was that you want your tables to contain movie titles. And just when we're getting our heads around that, it turns out that those other examples were bogus and we're actually going to store job titles, not movie titles. I understand that you sometimes have to "disguise" examples a bit because of your employer's confidentiality concerns but this has become a bit too much of a moving target. In some cases, the exact nature of the data makes a great deal of difference to the design an experienced person would recommend. A solution that is perfect for color may be far less ideal for movie titles or job titles because all of those things have different properties. If you're going to disguise your examples, please choose a good analogy the first time and then do your best to stick with it. It's just a lot less confusing all the way around. > Also, yes I would like to share my design at some > point for some critique. It maybe slightly premature, > but I will defintely ping you when I'm ready. > I'm certainly not insisting that you share your full design with this mailing list or even a major part of it. But it is EXTREMELY hard to verify that you are designing your database correctly with just a two sentence paraphrase of how you are planning to build your system. You probably learned the same phrase the rest of us did when we started working with computers: "Garbage in, garbage out". If you want good feedback from us, you have to give us good input, not just a quick paraphrase. The other thing is that you have to understand that any critique that people on the mailing list can give you is going to be relatively superficial: we are not going to do a full scale professional critique! All we can do is give it a once-over and point out the most obvious flaws. We are unlikely to catch the subtler mistakes in your design and we may even miss some of the obvious ones. If I were doing a *thorough* design critique, I'd want to see at least the conceptual design and the logical design and probably your best shot at the physical design. This involves some significant documentation, including a full E-R (Entity-Relationship) Diagram, your table layouts (including all primary and foreign keys), etc. etc. Without that sort of documentation, it would be extremely difficult to assess the actual viability of your design. I'd also have to interview you extensively to make sure I understood your design properly before critiquing it. I don't think that level of thoroughness is realistic for a mailing list so please understand that any critique we can do is going to be relatively superficial. Unless of course you are willing to pay our consulting rates ;-) Rhino > > --- Rhino <[EMAIL PROTECTED]> wrote: > > > I guess I'll have to wait until you've had a chance > > to mull the whole note > > over ;-) > > > > I really don't know what you're saying. I can't > > think of anything I said > > that would have discouraged you from creating the > > association table. > > Certainly the number of columns in the table > > shouldn't discourage you since > > there are typically only two columns and they are > > usually both short codes. > > > > The number of rows *may* be a concern though; if you > > have a lot of job > > titles and a keep track of every job every member > > has had, you could end up > > with a lot of rows. Maybe that's your concern. > > > > In any case, I hope you can explain what you are > > going to do instead of the > > association table if you have definitely abandoned > > it. Maybe we can critique > > that design for you and help you improve it or at > > least avoid the most > > common pitfalls. > > > > Rhino > > > > > > > > > > ----- Original Message ----- > > From: "Stuart Felenstein" <[EMAIL PROTECTED]> > > To: "Rhino" <[EMAIL PROTECTED]>; > > <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]>; "Stuart Felenstein" > > <[EMAIL PROTECTED]> > > Sent: Friday, August 27, 2004 4:47 PM > > Subject: Re: Many to Many: Does this make sense ? > > > > > > > Let me answer the first part now and then continue > > > reading. > > > > > > You absolutely gave me some great ideas / > > examples. > > > I understand it very well now. I'm abandoning it > > > solely because creating that association list -1) > > may > > > take forever and still come up way short 2)I see > > how > > > others have implemented the same type of > > application > > > and have not provided specific job title > > allocation. > > > > > > I hope that gets you settled back again! > > > Stuart > > > --- Rhino <[EMAIL PROTECTED]> wrote: > > > > > > > My replies are interspersed below. > > > > > > > > Rhino > > > > > > > > ----- Original Message ----- > > > > From: "Stuart Felenstein" <[EMAIL PROTECTED]> > > > > To: "Rhino" <[EMAIL PROTECTED]>; > > > > <[EMAIL PROTECTED]> > > > > Cc: <[EMAIL PROTECTED]>; "Stuart Felenstein" > > > > <[EMAIL PROTECTED]> > > > > Sent: Friday, August 27, 2004 3:05 PM > > > > Subject: Re: Many to Many: Does this make sense > > ? > > > > > > > > > > > > > Now I am totally clear on it! Took a few > > > > reiterations > > > > > but I'm there. Even more I'm going to abandon > > the > > > > > idea of titles. > > > > > > > > I was breathing a sigh of relief that we'd > > finally > > > > articulated the idea > > > > clearly enough. But now I'm not so sure.... > > > > > > > > What do you mean you are going to "abandon the > > idea > > > > of titles"? > > > > > > > > > > > > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
