InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comWed, 19 Jun 2013 23:05:59 GMT20http://www.sqlservercentral.com/Forums/Topic426244-373-1.aspxYou 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.Wed, 28 Nov 2007 12:22:23 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic426244-373-1.aspxOK. I'll go to the bottom of the nerd's class :(See if this works betterThere 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 solutionAt these locations, a Dealership enter details of a Contact they will be making with a Customer, e.g. name, telephone details etcAssociated with this contact is:-a SalesExecutive (or Sales Person if you like) at that Dealershipan 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 etcp.s. This data is currently held discreetly at Dealerships and will be in future stored centrallyWed, 28 Nov 2007 10:13:56 GMTDavid Burrowshttp://www.sqlservercentral.com/Forums/Topic426244-373-1.aspx[quote][b]Jeff Moden (11/28/2007)[/b][hr]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.[/quote]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.Wed, 28 Nov 2007 08:06:20 GMTMatt Miller (#4)http://www.sqlservercentral.com/Forums/Topic426244-373-1.aspx[quote]My most sincere appologies[/quote]No need Jeff :)[quote]I thought you were making fun of a series of threads that are responsible for the current inflamed crease in my gray-matter[/quote]Not me... but if you send me the thread I'll give it a damn good try... lol ;)Seriously though, this is a question I am struggling with and since your 'the man' on scalabilty I'd really appreciate any thoughts you may have. I am worried that this database will start off fine and rapidly 'go south' in a big wayp.s. Thanks for the feedback Ahmed :)Wed, 28 Nov 2007 07:43:34 GMTDavid Burrowshttp://www.sqlservercentral.com/Forums/Topic426244-373-1.aspx[quote]A location is a code varchar(10) and currently consists of 6 numeric digits where the first three are always zeros. [/quote]First, leading zeros tend to be for display and I probably wouldn't store the location ID's that way. I'd make the location either an INT, or possibly, because of the limited number of possibilities, a SMALLINT. I'd add a calculated column to the location table to display the SMALLINT value with the required leading zeros. It'll save on some storage space and possibly improve performance, a bit.As for the Executive and Contact tables...I'm not sure that I would separate these... I believe I'd put Executives in the Contact table with a flag that indicated they were executives. In either case, I'm not real sure how you would handle a Contact being promoted to an Executive status. I'd have to think about that.I'm a bit confused about ModelID and SourceID in the Contact table. It would appear that each contact is somehow responsible for a given Model or set of Model's from different sources. That's quite a bit of denormalization in that if, say, a given Contact was female and changed her name at the marriage event, you would have to change that name on more than one row. I believe that a cross-reference table between Contacts and Models would suite better. It does add some complexity as 3rd normal form has the tendency to do, but I believe it will be better in the long run in so far as maintainability goes.Also, if Models can come from different sources, I'd add the SourceID to the Model table and include that in the cross-reference table I spoke of... that would be a source of great relief for the normalization of the Contact table.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.Wed, 28 Nov 2007 07:38:04 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic426244-373-1.aspx[quote][b]David Burrows (11/28/2007)[/b][hr][quote]What? Oh? OH? OOOOOHHHHH!!! BWAAAA-HAAAAAA.....[/quote]Sorry Jeff...Did not know if you were laughing at me :crying:or at my question :(or was it that I actually posted one :blink:[/quote]Oh, bugger... I'm so sorry, David... my mind is really warped... I thought you were making fun of a series of threads that are responsible for the current inflamed crease in my gray-matter. My most sincere appologies.Wed, 28 Nov 2007 07:07:46 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic426244-373-1.aspxHi David,check this link a good site for database design http://www.databaseanswers.org/data_models/index.htmRegards,AhmedWed, 28 Nov 2007 03:04:04 GMTSQL_ABDhttp://www.sqlservercentral.com/Forums/Topic426244-373-1.aspxHi David,Like I see you have snowflake data model, If I really understood, for me, I will create a table location(locationId, locationName) and each table will have the location id as foreign key.Regards,AhmedWed, 28 Nov 2007 02:51:27 GMTSQL_ABDhttp://www.sqlservercentral.com/Forums/Topic426244-373-1.aspx[quote]What? Oh? OH? OOOOOHHHHH!!! BWAAAA-HAAAAAA.....[/quote]Sorry Jeff...Did not know if you were laughing at me :crying:or at my question :(or was it that I actually posted one :blink:Wed, 28 Nov 2007 02:36:15 GMTDavid Burrowshttp://www.sqlservercentral.com/Forums/Topic426244-373-1.aspx[quote]I am not sure what your question is?[/quote]Sorry Ron. I'll try to meke it clearer :blush:Thanks for the reply :)The data is separate by Location, ie the ContactID will unique to the Location as will be the SalesExecutive,Outcome etcWhilst using LocationID (and I left out a Location table on purpose as I did not want to constrain any design yet) will separate the Contacts by Location and by inference all it's associated data. I will need to retrieve all the SalesExecutive, Outcome etc for a specific Location irrespective of Contacts as a SalesExecutive may exists for a Location but not be referenced.The question is how to alter the design for performance and scalability.Three things occured to me1. A database per Location (140+ databases!!!)2. One database with tables repeated for each Location (partitioned views with 140+ tables!!!)3. Unique range of ID's per LocationAs I stated it is about performance and scalability.byw the Location of varchar(10) is fixed due to third party system, however the last 3 digits (1-999) is still in operation, but who knows for how long! it could changeWed, 28 Nov 2007 02:34:50 GMTDavid Burrowshttp://www.sqlservercentral.com/Forums/Topic426244-373-1.aspxWhat? Oh? OH? OOOOOHHHHH!!! BWAAAA-HAAAAAA-HAAAAA! WHOOOOO-IIIIEEEEEE! SNNOORRRTTT! Now, THAT's funny, David!!!! OMIGOD!!! I CAN'T QUIT LAUGHING!!!! TOO FUNNY, MR BURROWS!!!! OH! PHHHT! GOTTA CHANGE MY DEPENDS!!! HAAAA-HAAAA-HAAAA!!! LMAO!!!!Well done, David... I'll clear some of my PM's... we gotta have a laugh together about this one!Tue, 27 Nov 2007 17:32:41 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic426244-373-1.aspxI am not sure what your question is? However, the only idea I can surmise is you are missing a Locations table in your list and the location code "LocationID" should be a fixed char(6) field and not a varchar(10). Then you contacts table should have a LocationID foreign key to identify the location of each contact.Tue, 27 Nov 2007 15:30:54 GMTRon Kuncehttp://www.sqlservercentral.com/Forums/Topic426244-373-1.aspxSQL2KStarting with the following tables.SalesExecutive SalesExecutiveID NameOutcome OutcomeID OutcomeSource SourceID SourceModel ModelID ModelContactType ContactTypeID ContactTypeContact ContactID ContactDate ContactName SalesExecutiveID OutcomeID SourceID ModelID ContactTypeIDI have contacts that are linked to other tables by ID's. To start with all the tables will be empty and a Web app will create all the data as and when necessary.Now I want to introduce locations. A location is a code varchar(10) and currently consists of 6 numeric digits where the first three are always zeros. There are approx 140 locations with last three digits consisting of any number in the range 1-999 and are not consecutive. The number of locations will increase and normally no number is reused.All the data in the tables has to separated by location as each location has it's own values and a location may not see or use each other's data.Each location can have thousands of contacts per year and any number of SalesExecutive,Outcome,Source,Model,ContactType linked to them.Any ideas?Tue, 27 Nov 2007 02:59:59 GMTDavid Burrows