help on developing an php-based recruiting sys

[pe_es171]

i need sm1 to put me thro on developing a php-based online recruiting sys.i'm having three users in mind.(Job-seekers,Employers,ADMIN).under Jobseeker module,i want it to store d profile info,membership and resumé.d profile info should include username,password,email,photo,mobile no,contact address.in d membership,it should include FREE or PREMIUM***where only d premium can apply for jobs and comment.in d resumé,der must be link to d uploaded resumé by d user.Under d employer,i want it to contain profile info,create vacancies option.in d profile info,d company name,address,mobile no,description,email.My questn is- USING MYSql,HOW MANY DATABASES AND TABLES WILL I CREATE?

[cybrax]

Well... if you think about it matching people with jobs is
pretty much the same as matching them with lovers.
So you might be able to get some ideas from dating
scripts like OsDate (it's a free download).

As for the business plan to charge job seekers money in order to contact the employer

IMHO I don't think it will work because employers often share the vacancy details with more
than one recruitment agency. here in the UK agencies are often only allowed to submit two candidates
for each for vacancy because there are so many.

Secondly recruitment agencies traditionaly make thier money
by charging the employer for a succesful placement, so would suggest some market research.

Thirdly, asking somebody with little or no money to pay for job vacancy details... sounds like preying on the desperate

[essellar]

Hmmm, let's see... you need one database and more than one table. Really, that's about all anyone can give you based on what you've said so far. Okay, you have two majors "classes" of people defined as users -- those seeking employment, and those who can offer employment. That's nice. That's also trivial and, from the perspective of making this thing work, almost completely irrelevant.

The application you envision is only tangentially about matching people. It's really about matching skills with opportunities, and so far you have those defined as unimportant "blobs" of stuff (a resume/CV on the one hand and a "vacancy" on the other). I suppose you could try to do a full-text merge and see what happens, but the chances are pretty good that most of your matches are going to wind up being between one person's hobby and another's address. You have a lot more thinking to do before it's time to start designing a database.

And if the primary users of the site are going to be technical types or other "inside workers", lose the idea of the photo altogether -- it's a filthy habit unless the vacancy is for a model or a public spokesperson. It doesn't matter if it's customary in your area; sometimes you have to choose to do what's right instead of what's expected.

And, as Cybrax pointed out, it's the employers, not the job-seekers, who should be paying for all of this. It's okay to force people to give you all of their information in order to see the opportunities, and it's okay to hide the details that would keep the two parties from linking up outside of your agency until a request (indicating intent, and therefore liability for payment) has been registered. It is never okay to ask for payment from a job-seeker up front (and in many jurisdictions, it would be illegal to take money from a successful applicant after hire unless you have an ongoing contract of exclusive agency). Your talent pool is your product; businesses looking to hire are your customers, and the service you provide is saving them the time and expense of finding the right product in a large warehouse.