Follow up

Hi all,

I've designed a database for a recruitment site, this is the my first time to design such a complex model, I feel that I have gone so far over-normalizing this database and made it too complicated. I need your comments/suggestions on its design. Please bear with me and I'll provide you with any details you might need.

An image of the database design model is herehttp://wunex.blogspot.com

[508 byte] By [loopool] at [2007-12-24]
# 1
?

My first reaction is that it doesn't look too

complicated at all. I just looked through all of the tables and it looks

like you've done a nice job -- it's easy to understand what everything is

there for, and I think it's fairly good as-is. However, I might actually

suggest that you break things out even more than they are. I don't know

your business requirements, but there are a couple of things you can do if you

want to go further:

A) PostedJobs has a City column. That will

help you with exact matches, but did you ever think of letting people search for

jobs near them? To do that, you'll want to get a table of ZIP codes and

lat/lon pairs. See: href="http://databases.aspfaq.com/database/how-do-i-create-a-store-locator-feature.html">http://databases.aspfaq.com/database/how-do-i-create-a-store-locator-feature.html

B) Resumes has a Skills column. Putting

everything in one column might make searching difficult, depending on how you're

planning to index this thing. Will you use FTS for this system? If

not, you might want to create a ResumeSkills table, with columns ResumeID,

Skill, and maybe an additional column for detail like "NumberOfYears" (i.e., the

number of years the person has used that skill).


--


Adam Machanic
Pro SQL Server 2005, available now
href="http://www.apress.com/book/bookDisplay.html@bID=457">http://www..apress.com/book/bookDisplay.html?bID=457
--

style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">

< href="mailto:loopool@discussions.microsoft.com">loopool@discussions.microsoft.com>

wrote in message href="news_3A672fae8e-57a8-4a9d-a09c-975f856695d7_40discussions.microsoft.com">news:672fae8e-57a8-4a9d-a09c-975f856695d7@discussions.microsoft.com...

Hi all,

I've designed a database for a recruitment site, this is the my first time

to design such a complex model, I feel that I have gone so far

over-normalizing this database and made it too complicated. I need your

comments/suggestions on its design. Please bear with me and I'll provide you

with any details you might need.

An image of the database design model is here href="http://wunex.blogspot.com/default.htm">http://wunex.blogspot.com

MVPUser at 2007-8-31 > top of Msdn Tech,SQL Server,SQL Server Database Engine...
# 2

First off, thank you for your encouraging initial opinion of my design

Right now I'm too confused, before I choose to put a single skills column which will hold all of the applicant's skills, l was thinking to pick some general key skills and put it in a separate table, then filling that table with these pre-determined skills, then I could use a junction table to link those skills with applicants' resumes as there would be a many-to-many relationship between resumes and skills. Then I was facing a serious cumbersome in another tables; like the Resumes_Languages junction table. I used this table to reflect the m-m relationship between the resumes table and languages table which has some pre-determined languages to specify the proficiency of every language selected per applicant, so I decided to create yet another table named LanguageProficiency and linked it to a FK in the languages table: see http://wunex.blogspot.com

Someone told me that I should avoid junction tables and started to talk about cross-reference and things I don't understand, so if he's right what wrong with junction tables and when I should/shouldn't use them.

Another question is about lookup tables when I should use them and when I shouldn't

loopool at 2007-8-31 > top of Msdn Tech,SQL Server,SQL Server Database Engine...
# 3
?

There is nothing wrong with "junction" tables --

they are required for implementing many-to-many relationships. There is

really no other way to do so in SQL databases, so if you need a many-to-many

relationship, you need a table -- there is no way to avoid it.

Lookup tables -- you already seem to have a good

handle on that. Use them liberally; any standard data that you'll see

again and again should go into a lookup table to avoid data integrity issues and

allow you to simplify queries. Your languages example is a great

one. If you have a lookup table, you can easily find all applicants who

speak Spanish, and you'll lower or eliminate the possibility of someone typing

in that they speak "Spnaish" (or some other misspelling), which would make it

much more difficult to identify that applicant later if you need a

Spanish-speaking candidate.


--
Adam Machanic
Pro SQL Server

2005, available now
href="http://www.apress.com/book/bookDisplay.html@bID=457">http://www..apress.com/book/bookDisplay.html?bID=457
--

style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">

< href="mailto:loopool@discussions.microsoft.com">loopool@discussions.microsoft.com>

wrote in message href="news_3A70841fc5-4a0c-4871-b595-0a62f22a634d_40discussions.microsoft.com">news:70841fc5-4a0c-4871-b595-0a62f22a634d@discussions.microsoft.com...

First off, thank you for your encouraging initial opinion of my design src="images/emoticons/smile_wink.gif">

Right now I'm too confused, before I choose to put a single skills column

which will hold all of the applicant's skills, l was thinking to pick some

general key skills and put it in a separate table, then filling that table

with these pre-determined skills, then I could use a junction table to link

those skills with applicants' resumes as there would be a many-to-many

relationship between resumes and skills. Then I was facing a serious

cumbersome in another tables; like the Resumes_Languages junction table. I

used this table to reflect the m-m relationship between the resumes table and

languages table which has some pre-determined languages to specify the

proficiency of every language selected per applicant, so I decided to create

yet another table named LanguageProficiency and linked it to a FK in the

languages table: see href="http://wunex.blogspot.com/default.htm">http://wunex.blogspot.com

Someone told me that I should avoid junction tables and started to talk

about cross-reference and things I don't understand, so if he's right what

wrong with junction tables and when I should/shouldn't use them.

Another question is about lookup tables when I should use them and when I

shouldn't

MVPUser at 2007-8-31 > top of Msdn Tech,SQL Server,SQL Server Database Engine...
# 4

Ok, the person who suggests avoiding junction tables has presented me with another design. Now, because this will be applied on more than one table in my database, I need to know which approach is better and why?

Thank you very much for your time.

The alternative approach is here: http://wunex.blogspot.com/

loopool at 2007-8-31 > top of Msdn Tech,SQL Server,SQL Server Database Engine...
# 5
?

I guess our definitions of "junction table" differ,

because what I see there IS what I would call a "junction table" (the

Resumes_Languages table). That's exactly the approach I suggested in

my first reply.


--
Adam Machanic
Pro SQL Server 2005, available now
href="http://www.apress.com/book/bookDisplay.html@bID=457">http://www..apress.com/book/bookDisplay.html?bID=457
--

style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">

< href="mailto:loopool@discussions.microsoft.com">loopool@discussions.microsoft.com>

wrote in message href="news_3A11b5a3b8-ce5e-407b-a23f-938c799dd68a_40discussions.microsoft.com">news:11b5a3b8-ce5e-407b-a23f-938c799dd68a@discussions.microsoft.com...

Ok, the person who suggests avoiding junction tables has presented me with

another design. Now, because this will be applied on more than one table in my

database, I need to know which approach is better and why?

Thank you very much for your time.

The alternative approach is here: href="http://wunex.blogspot.com/default.htm">http://wunex.blogspot.com/

MVPUser at 2007-8-31 > top of Msdn Tech,SQL Server,SQL Server Database Engine...
# 6

No, we have the same definition of a "junction table" because what you refer to as a junction table (the Resumes_Languages) table is what I also call a "junction table", so we have the same difinition for the same thing

The point is I'm comparing this "junction table" with someone else's approach to implement the same desired capability of this junction table and the extra "LanguageProficiency" table.

What I want to model is:

Every applicant (ResumeID) can have more than one language.

Every language in the languages table can be selected by more than one applicant

The language proficiency of every language selected by a given applicant can be specified

My approach is the junction table and an extra LanguageProficienct table linked to it to further specify the proficiency attribute per language per applicant.

His approach http://wunex.blogspot.com/

is to create a table named LanguageSkills whith a (ResumeID, LanguageID) as PK and another two fields describing the written and spoken proficiency of a selected language.

A second table which will hold the Languages

A third table that will hold the proficiency values

So, all I need to know is what is the difference between the two approaches and which is better and why.

Thanks again

loopool at 2007-8-31 > top of Msdn Tech,SQL Server,SQL Server Database Engine...
# 7
?

OK, I see what you're saying. I think his

approach is better, because it more accurately and flexibly reflects the reality

of what you're modeling. In your approach, if you add a new language you

need to insert one row for each proficiency before you can use it for a resume;

in his, you can insert new languages and proficiencies and use them as

needed...


--
Adam Machanic
Pro SQL Server 2005, available now
href="http://www.apress.com/book/bookDisplay.html@bID=457">http://www..apress.com/book/bookDisplay.html?bID=457
--

style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">

< href="mailto:loopool@discussions.microsoft.com">loopool@discussions.microsoft.com>

wrote in message href="news_3A9502037f-f04c-4e19-8430-86151d44a17f_40discussions.microsoft.com">news:9502037f-f04c-4e19-8430-86151d44a17f@discussions.microsoft.com...

No, we have the same definition of a

"junction table" because what you refer to as a junction table (the

Resumes_Languages) table is what I also call a "junction table", so we have

the same difinition for the same thing src="images/emoticons/smile_wink.gif">

The point is I'm comparing this "junction table" with someone else's

approach to implement the same desired capability of this junction table and

the extra "LanguageProficiency" table.

What I want to model is:

Every applicant (ResumeID) can have

more than one language.

Every language in the languages

table can be selected by more than one applicant

The language proficiency of every

language selected by a given applicant can be specified

My approach is the junction table and an extra

LanguageProficienct table linked to it to further specify the proficiency

attribute per language per applicant.

His approach href="http://wunex.blogspot.com/default.htm">http://wunex.blogspot.com/

is to create a table named LanguageSkills whith a (ResumeID, LanguageID) as

PK and another two fields describing the written and spoken proficiency of a

selected language.

A second table which will hold the Languages

A third table that will hold the proficiency values

So, all I need to know is what is the difference between the two approaches

and which is better and why.

Thanks again

MVPUser at 2007-8-31 > top of Msdn Tech,SQL Server,SQL Server Database Engine...

SQL Server

Site Classified