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.

 All Forums
 General SQL Server Forums
 Database Design and Application Architecture
 Refactoring...how much is too much?

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:
id
first_name
last_name

Contact:
id
name_id
...

Salesman:
id
name_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.
Go to Top of Page

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


- Jeff
http://weblogs.sqlteam.com/JeffS
Go to Top of Page

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
Go to Top of Page

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!
Go to Top of Page
   

- Advertisement -