Joins vs More Columns

  • I agree with all of that. I am going to consolidate this advice into doc for my boss and 'hopefully' he will pay attention to it. But I'm not keeping my hopes up (he thinks he understands databases but is basing his understanding on old-school DBs - not on modern RDBMS)

    I'll try to keep you posted on any more arguments he brings up.

  • I think Tom stated it best. Your design with the 3 tables allows you to have the situation where you need to add a new type of address or phone number to your database WITHOUT making a database change and possibly without even changing any code! If your boss doesn't see that as a benefit then grumble a lot about wasting money and do it his way!

    Also I would put 2 more tables in the schema for Phone Type and Address Type but that's just me!




    Gary Johnson
    Microsoft Natural Language Group
    DBA, Sr. DB Engineer

    This posting is provided "AS IS" with no warranties, and confers no rights. The opinions expressed in this post are my own and may not reflect that of my employer.

  • Yeah, I didn't put those tables in my list because they weren't pertinent to the discussion. I'm definitely planning on splitting that out too (if I get the go-ahead)

  • Just because I'm feeling a little bitter today, Your boss is probably the same person that code select * from table instead of a list of columns.  That's good design too.

    Tom

  • Yep. He did do that. When I went and cleaned up the code I removed all those Select * to just the neccessary columns.

    He is also the guy that in order to get the number items in the returned recordset, did this:

    while not rs.eof

     

Viewing 5 posts - 16 through 19 (of 19 total)

You must be logged in to reply to this topic. Login to reply