Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Database Design Question Expand / Collapse
Author
Message
Posted Wednesday, November 28, 2007 8:06 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 4:32 PM
Points: 7,152, Visits: 15,633
Jeff Moden (11/28/2007)

Once that were accomplished, then I believe there would be no need for separate tables or databases for each Location. Simply add the LocationID to most of the tables. Properly indexed, I don't believe performance or scalability will even come close to being an issue.


Agreed - once you update your relations (or th right subset of your relations) to be compound relations to include the old FK to now be FK+locationID, you should be able to have all of the separation you need. I'm still not clear on where it fits in precisely, because the requirements are a bit fuzzy, but this works fairly well.


----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Post #426910
Posted Wednesday, November 28, 2007 10:13 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 10:02 AM
Points: 6,997, Visits: 7,155
OK. I'll go to the bottom of the nerd's class

See if this works better

There are locations (Dealers) that represent a Car Dealership that sells cars. The code for the dealer is varchar(10) containing 6 numeric digits where thr first 3 are zero (eg 000123) this I cannot change due to external systems however it is possible to convert the last 3 digits to int but this would constrain the system if this ever changes but I am prepared to accept this for an easier solution

At these locations, a Dealership enter details of a Contact they will be making with a Customer, e.g. name, telephone details etc
Associated with this contact is:-
a SalesExecutive (or Sales Person if you like) at that Dealership
an Outcome (Sale, Lost Sale etc)
the Source of the contact (Direct Mail, Local Awareness etc)
the Model (of car) the are interested (at this time Dealerships can enter their own description not sure if this will change to dedicated central list)
the type of Contact (Walk-in, Telephone etc)

Dealerships will maintain their list of names of SalesExecutives, Models etc

p.s. This data is currently held discreetly at Dealerships and will be in future stored centrally



Far away is close at hand in the images of elsewhere.

Anon.

Post #426969
Posted Wednesday, November 28, 2007 12:22 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 11:08 PM
Points: 35,547, Visits: 32,135
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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #427035
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse