hey guyz, i have project, i have to design a website starting from the scratch, so i was developing the ER diagrams for it. The website is going to be like bestjobsusa.com, infact with quite less options in it.Basically i m havin lots of problems in designing it.let me tell u till where i have done
3 db's
1.Employer
2.Job seeker
3.Login db

here comes the difficult part (atleast i m findin it difficult). These contain the as usual attributes like the name,personal information etc... creating the relations is making me go wild.
If anybody could help, then thanks a lot.........

OK... Start with a conceptual model. What are you designing ?

A system that links job seekers to employers?

Job seekers and employers are roles that people and organizations play. Think about this. Suppose today I (Joe Bobb) am looking for a job. I get tired and start my own business, which surprisingly does real well, so I have to hire some help.

Now am I 'magically' a different person because I'm an employer?

A single individual person can play MANY roles. However.... you've implied that you are forcing people (and organizations) into one of two roles.
Either you're a job seeker, or a job provider.

RIGHT?

No... not right. Don't EVER EVER EVER force somebody into a role because the business will change and then your design breaks. How about this? If you enter a company like IBM as an employer or job provider, then how is someone to contact this monster corporation. OF COURSE.... the organization can't speak or talk by itself, but it has an HR Person who represents the company and that is who you contact. See, I just found another role a person plays

Have an entity called people, one called organization, one called roles and create an associate entity between them.

This will allow ANY combination of people or organizations to be related to each other defined by the roles they play.

As far as the login... related that to a person as a separate entity, you might encrypt that.

Vmusic

well ur rite, well the HR( or any one responsible ) of the comapny will represent the orgainzation,well let me it more clear, i was thinking of it to be something like this shown below. The user logs in as anyone of the employer or the jobseeker and respectively searches for each other. i assume havin an organization and then the roles for it would be somewat different.

Hi,
Sorry to be so rude. I use the idea of abstraction in design. If you use to a sensible level, it will save YEARS of change.

So you have a business entity Job Seeker and Employer

I 'abstracted' these. It was as if you said I have an apple that's looking for a horse

I see that as a 'fruit' looking for an 'animal'.

You don't HAVE TO do that.... but as soon as your design needs to work for something other than a job_seeker - it's broken

I am assuming the only thing or the only rows I'll ever find (from the table name, the only rows I should ever find) in your job_seeker table is a job_seeker.

Then where will store the employer's representatives? (HR), head hunters, etc.?

So I abstracted a job_seeker and said they're a person, in a specific role.

I hope you understand. Abstraction can be difficult to understand, but it will save you so many times as I assure you... the business will change.

Enjoy!
Vmusic

There are always several solutions to a problem.

To add to what Vmusic has contributed I suggest diagram 1 uses a supertype subtype hierarchy to separate the two roles in a somewhat concrete fashion and then joining with an associative entity.

The second diagram suggests using a role to identify the type of account it is and then a job seeker to employer relationship using an associative entity.

Thanks a lot dudes

Another man fed for a day.

does n e 1 know what program certus is using for the ER diagrams he has posted for this thread?

if so where can i get it from?

i believe it is dbdesigner4