Database Schema Design
Hello Experts,
I'm looking into building my own application that will allow me to enter Customer Information based on Computer Repair work from my clients. I plan on building the application in ASP.NET MVC 5 using either Entity Framework Code First or Database First approach (not sure which method I'm going to use, still deciding) in C#. Before we begin, I will stress that I'm new to MVC and Database Design.
So, I have sketched out in Notepad how I think the Database Schema Design should be laid out but obviously not sure since I'm asking for help here.
Please see the attached file....
Also, please advise me if I need to correct the naming of my table fields. Not sure if there is a standard that I should follow. If so, please advise how I should go about proper naming of fields in my tables.
DatabaseDesign.txt
I'm looking into building my own application that will allow me to enter Customer Information based on Computer Repair work from my clients. I plan on building the application in ASP.NET MVC 5 using either Entity Framework Code First or Database First approach (not sure which method I'm going to use, still deciding) in C#. Before we begin, I will stress that I'm new to MVC and Database Design.
So, I have sketched out in Notepad how I think the Database Schema Design should be laid out but obviously not sure since I'm asking for help here.
Please see the attached file....
Also, please advise me if I need to correct the naming of my table fields. Not sure if there is a standard that I should follow. If so, please advise how I should go about proper naming of fields in my tables.
DatabaseDesign.txt
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>> At this point use full business-related names, not lots of abbreviations
Can you explain better to me what you mean, sorry. <<
Rather than "cusID", use "Customer ID". Instead of "stID", use "State ID". You are still in the logical design phase, where purely business people, with no computer background, should be able to read and contribute to the data entities and attributes.
As to the rest, you'll have to do some reading on logical and physical db design. There is no way I can do a full background for that in the context of a single q (or, in this case, a list of qs).
Can you explain better to me what you mean, sorry. <<
Rather than "cusID", use "Customer ID". Instead of "stID", use "State ID". You are still in the logical design phase, where purely business people, with no computer background, should be able to read and contribute to the data entities and attributes.
As to the rest, you'll have to do some reading on logical and physical db design. There is no way I can do a full background for that in the context of a single q (or, in this case, a list of qs).
ASKER
>> At this point use full business-related names, not lots of abbreviations
Can you explain better to me what you mean, sorry.
>> Again, use fuller names not abbreviations. Use IDs rather than natural keys only if you need to
Can you explain better to me what you mean, sorry.
>> Next, determine keys of Entities and logical relationships between Entities ("has a", "is a", "orders", etc.).
Can you explain better to me what you mean, sorry.
>> Then -- and only then -- convert to tables as you normalize the data. Go thru each normalization level one at a time.
Can you explain better to me what you mean, sorry.
>> On the physical side, use ids as identifying column when needed
Can you explain better to me what you mean, sorry.
Also, as for Customer Address. I plan on updating the data as my clients may move. I will be checking each time I work with them. So if I work with John Doe today and then a month from now if I have a different address then I will update that in the database.