• You could probably get away with the VARCHAR location ID.

    On the other, consider this... what does a dealer need most? Customers? What would a dealer need to trend customers? Customer information. You need to be able to track repeat customers, customers that buy more than one vehicle/model in the same transaction (usually business/fleet customers), and the occasional person who says "I'd buy one today if you had a blue one" (cross dealer sales).

    Given the revelation about your scenario, yeah, I think I'd split the SalesExecutive (employee) table from the Contact (customer) table. But, I'd still relieve/normalize the Contact table as I've previously mentioned. This is not only a sales tracking system, it's a customer management system. The cross-reference table would help meet all current and many future needs. I don't believe that denormalization of the Contact table is correct even though there's a very specific purpose you currently have in mind... you have to be able to let it grow and support new requests for information without much (if any) change to the underlying tables. Why? Makes you look good as a Designer and that's good for repeat business and referrals. Plan for the unexpected and keep the tables normalized.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)