Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
puritysdisciple
Starting Member
2 Posts |
Posted - 2007-08-28 : 18:16:44
|
I have a new database that I am designing. I come from a programming background, so as far as I am concerned nothing should ever be repeated, and if it is, refactor it.I am getting to the point where I am not sure if I am refactoring too much. For instance I have a contact table which contains a first_name, and a last_name. This also shows up in a salesman table that I have. So I refactored it to a name table:Name:idfirst_namelast_nameContact:idname_id...Salesman:idname_id...I am going to far with my refactoring, or am I still on the right track? I figured I would ask this early before I get waist deep in refactoring something that needs to not be refactored.Thanks in advance |
|
rmiao
Master Smack Fu Yak Hacker
7266 Posts |
Posted - 2007-08-28 : 20:44:34
|
Still on right track IMO. |
 |
|
jsmith8858
Dr. Cross Join
7423 Posts |
Posted - 2007-08-28 : 21:45:35
|
Wrong track. A name is not an entity, it is just an attribute. What reason do you have for putting all "names" in the same table? What does this gain?Now, if instead of name you have a table of generic Contacts, or People, or an actual Entity along those lines, and if those entities have other attributes or relations, then you may be on to something. But I doubt you really need to define a "name" entity, it doesn't seem to make much sense. You also are probably storing dates and numbers throughout your tables -- should you have a Numbers table and a Dates table and make every number or date a relation to those tables? Most likely not.The thing about data modeling is: it is very hard to give advice without knowing exactly what you are modeling and what the rules are. Just showing a table and asking "is it right?" can help find obvious mistakes, but you can never know for sure if a table or schema design is a good one without knowing the logical model that it is representing.A little more on the topic here: http://weblogs.sqlteam.com/jeffs/archive/2007/06/19/60238.aspx- Jeffhttp://weblogs.sqlteam.com/JeffS |
 |
|
Kristen
Test
22859 Posts |
Posted - 2007-08-29 : 06:31:56
|
Slightly tangential thought:Sounds to me like you now need "Version Two" of your table design/schema.We tackle that by creating "MyTable_V2" in place of the original "MyTable". We copy the data over from MyTable to the new MyTable_V2, and Drop MyTable.Then we then create a VIEW called MyTable that maps to MyTable_V2 - and possibly also a JOIN to MyContactNames or whatever (although mostly we just use this approach when we say "That was a crap name for that column, Version Two is better" !!Kristen |
 |
|
puritysdisciple
Starting Member
2 Posts |
Posted - 2007-08-29 : 09:02:18
|
The "person" table is more along the lines of what I need to make from what I am getting. I was thinking about this concept on my way to work, and indeed you all have confirmed it. Thanks a lot for the advice! |
 |
|
|
|
|
|
|