July 27, 2004 at 10:33 am
Hi experts!
We are working on the Human Resource website which allows job applicants to upload their resumes to us, and we want to store those resumes in our SQL Server 2000, so that HR person can retrive from it anytime.
Does anyone has any idea how to do it?
Thank you.
Jennifer
July 27, 2004 at 10:59 am
Just some thoughts. You could force people to fill in a form with predefined info on it and call that the resume. The advantage is you are more likely to get the information you want but you may miss other important information. Otherwise you could allow people to upload a resume in any format. You could restrict it to say only Word or HTML but the actual resume format is up to the individual. If you do this you need to decide if you are only accepting resumes for specific jobs or general resumes good for a certain period of time that can be searched by HR to match up to some future job. It may be easiest to start by only accepting resumes that match to a specific job. You likely want to capture at least the persons name and contact info and store that in one table that is linked to the job table. The resume could then be a text column in the applicant table. You need to decide if you are going to allow online searching of the resumes or just a way to print them or view them without being able to search. Searching the resumes is more useful but it means implementing full-text searching on your database. I would develop this incrementally giving the HR are time to see each new feature. The HR area may have a good idea of what they want but more likely they just want resumes online and have no idea what they want to do with this system.
Francis
July 27, 2004 at 11:05 am
There are several methods you could use depending on what your requirements are. Since you are talking about resumes, as opposed to applications, there is no predetermined format with a known (or knowable) set of attributes that they can be broken down into. Other than some identifiying attributes of the applicant, the date, and maybe file type there probably isn't much that you can actually store other than the file itself. As for the file you can store it "in the database" as a varbinary or image data type. The varbinary has a theoretical limit of 8k, but in reality it will be less because you have to subtract the combined length of all the other columns. Image is probably the best bet as it can store up to 2Gb files.
The other alternative, and the one I tend to like a bit less, is to store the resumes as seperate files and just store the path to the appropriate file in the database. The primary disadvantage of this method is that your database backups do not include the resume files, so care must be taken to ensure recoverability and consistency i.e. a resume can be deleted but the record in the database that points to it is still there and vice versa.
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
July 27, 2004 at 11:48 am
Hi,
I would combine both previous replies. I would certainly store resumes as individual files with storing the path in SQL Server. Your developers have to write a simple attachment front end for that. As for the backups, database backups on the disk should be backed up to tape anyway so both Database Backup files and Resume files could go to tape at the same time. Or create a second step for the backup job that is an OS Command. Use Copy command to copy all relevant files to Network location.
I would also store a second copy of resume text in the Text field. Without all that formatting it is not a lot of storage space. But it will give you the ability to search. And then have several key fields like ID, First Name, Last Name. Also create a second table with skills ID and skills description. A person who will do the data entry will have to select from a dropdown based on this second table data.
Finally create a many-to-many table with 2 fields: ApplicantID and SkillID that will match applicants and skills
Regards,Yelena Varsha
July 28, 2004 at 2:12 am
Hi, I'll give you some info on how I last achieved this for a recruitment company here in London. (I'm not sure if another post has already included this information as I havent had a chance to read them, just got in the office)
Firstly, the table schema was set up to accept the path to a physical file, in any format (commonly, text, word, pdf, et al)
Aswell as storing the path to the file, it also stored user-entered keywords which they can associate with their uploaded resume. A Full-Text Index was applied on this field.
This way the client application can search the client table for the keywords, and then if a match (or matches) are successful then shell the associated application for the resume stored in the path.
So in short, tack onto your Candidate table a field for ResumePath and Keywords, have the candidate whilst uploading his resume fill in the keywords section.
hth,
Alex
July 28, 2004 at 10:59 am
For starters, check the following url . . .
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqlmag01/html/BLOB.asp
I used this and other articles I found to build a Web application for an online catalog. The images are initially uploaded to the database and then later sent to a file directory. When reading back the images the application checks the recordset of file names against the physical files on disk. If any are missing it creates / recreates the required file. I found this to be a good combination of security / backup and speed, since the files are usually just read from disk for the Web request.
Best regards.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply