Gossamer Forum
Quote Reply
Resume Database
I'd like to get an estimate from someone on setting up a resume datatbase - using either LinksSQL or DBManSQL. (Links probably preferable.)

Job Seekers would be able to upload resumes to selected categories and Employers would be able to view database summaries of Job Seekers but would be on a paid subscriber basis for downloading/accessing the resumes directly.

Requirements are for the functionality and follow-up tech support (if needed). There is not a need for graphic or other design functions.



Quote Reply
Re: Resume Database In reply to
how do you intend to do the paid-subscriber portion?

PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
Quote Reply
Re: Resume Database In reply to
In Reply To:
Job Seekers would be able to upload resumes to selected categories
The FILE UPLOAD/ATTACHMENT MOD that pugdog created would work for this.

In Reply To:
Employers would be able to view database summaries of Job Seekers but would be on a paid subscriber basis for downloading/accessing the resumes directly.
This would be a bit tricky...what you would have to do is use .htaccess to password protect the RESUME FILE directory in addition to the regular authentication used in LINKS SQL.

What you could probably do is EXPORT username/password into the .htpasswd file based on another column in your Users table called something like Subscriber (Yes/No). You should also include JOB SEEKERS in this scheme, so that they can view their resumes.

But differentiating between an "Employer" and "Job Seeker" would be difficult in terms of the database design and form/file access.

Regards,

Eliot Lee
Quote Reply
Re: Resume Database In reply to
In Reply To:
But differentiating between an "Employer" and "Job Seeker" would be difficult in terms of the database design and form/file access.
Actually, not. A job-seeker would be easily defined as someone who posts a resume, and such a person would have access to that record, and that record only, for updates/changes/etc.

Anyone else would be considered an "employer".

"employers" who had subscribed could view resumes, which is why I asked how the subscriptions was going to be handled.


PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
Quote Reply
Re: Resume Database In reply to
Not that simple, pugdog...A "JOB SEEKER" could also be an "EMPLOYER" if you look at the "job market"...meaning that their "statuses" would blur...Wink

And also, shouldn't "JOB SEEKERS" also be able to view their own resumes??? And if the resumes are kept in a password protected folder, then how would they be able to view them along with "EMPLOYERS".

So, in other words, this is NOT an easy puzzle to solve, if you ask me....poses a lot of database design and form/file access problems.

Regards,

Eliot Lee
Quote Reply
Re: Resume Database In reply to
No, you are making it too complex.

It's the same as a "user" and a "linkowner".

A job seeker is an employer if they pay fee, an employer is a job seeker only if they have uploaded a resume. A "user" (or non user) is someone who has not registered, or has registered but has not uploaded resume or paid a fee to view resumes.

No need for password protected databases if the information is stored in links, and the authorization is in the User table/record. Just a lot of "if" tests in the templates.

This is why I asked how the payments/authorizations were going to be handled.

I would store the resume in a MySQL table, not on-disk, and either have the user enter information in fields, or use a free-text box -- or a combination of both. This allows better keyword searches without redundant data input. Links manages the entire process -- except the collection of fees and setting employer access.

PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
Quote Reply
Re: Resume Database In reply to
I still see a problem with accessing the files, if Karen still wants files uploaded.

yes, putting the information into the database via web forms would be the best to ensure that data is only seen by the ResumeOwner and Paid Employers...HOWEVER, how would you address Karen's request to have a file upload option??? - where only paid employers and resume owners can view resumes???

Seems like a complex puzzle to me, Robert....Wink

Regards,

Eliot Lee
Quote Reply
Re: Resume Database In reply to
Not complex at all.

The resume uploader is the "LinkOwner". Simply put

<%if LinkOwner%>
<%include resume.html%>
<%endif%>

Where resume.html can be a form.txt type of file, that allows update/edit as well as display.

And to allow the employer to view the records, you'd modify search.cgi or page.cgi just slightly to check

if ($USER->{paid_status}) { do.....} else {return 'You must become a member to use this feature.');


To build the site statically, would require a bit of thought, but just have static build ignore the <%resume%> fields completely, easy if you put them in a separate table linked to the Link Record by Link_ID and User table by Username.

The trick is how to set the <%paid_status%> flag, since that requires a bi-directional transaction gateway. ccBill or iBill might work, but you need to pass in the payment data, then have the script pass back the authorized info to another script that sets the User table field <%paid_status%>, and an <%expire%> field, just for completeness.

I've been living/breathing this portion of Links for 6 months now! Some things I still don't get, but this sort of toggle/access is easy with the current user records. It gets harder if you want to assign "editors", but simple status flags that set what options are available to a user/surfer/visitor are easy. Especially if the types of data (fields) are known before hand, as with a resume, which has a few required fields, then a searchable TEXT field.

I actually do that on most of my sites. Admin and Editors automatically see a button that allows them to click/edit a link from the display screens, and Link owners get shown more detail information, etc.



PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
Quote Reply
Re: Resume Database In reply to
Okay...form access would not be a problem...but you still have not addressed Karen's request to UPLOAD RESUMES...which if they are NOT in a password protected folder, ANYONE can view them, which would defeat Karen's request to only allow paid employers to view the resumes.

How would you address this issue???

The reason I ask is that I am attempting to do something similar for my resume/job posting site...so, any insight you can provide on this matter would help...

Regards,

Eliot Lee
Quote Reply
Re: Resume Database In reply to
Just what I said before. You upload them INTO the MySQL database. No password protected directory needed.

Or, if you insist on having them outside MySQL for some reason, put them outside the document tree, and the cgi-script (page.cgi/template.pm) will simply include and output the resume.

Inside MySQL they are searchable... outside, they are pretty useless.

PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
Quote Reply
Re: Resume Database In reply to
WOW! Lots of interesting dialogue on this topic. A big thanks to both pugdog and Eliot!

Regarding payment - a decision on payment gateways has not yet been made however, leaning very much toward the Authorize.net payment gateway. The gateway is able to have scripts provide the gateway authorizations and can deliver back whatever codes are defined in the thru/via the gateway ... user can input the code/routing.

File upload would be a definite - common file formats, Word Docs for example. Pugdog, I'm not so sure on uploading the file into the SQL table, it would seem much easier for maintenance, troubleshooting, any sort of manual intervention to have the files actually uploaded to the server and use the script to call the file.

The Job Seeker would complete a form that would include locale, keywords, etc so having the actual [uploaded] document searchable wouldn't be a key element.

Now the tough part ... availability to do the project, estimated cost for the functionality, and timeframe to complete the modifications. Thanks!

Quote Reply
Re: Resume Database In reply to
Excuse my ignorance with regards to "uploading to MySQL database"...how is the uploaded file "stored" in the database? I am confused about this, because I have not looked at uploading files directly into the database.

Is the file stored as a BLOB type in a table or what? Please explain or better yet, if you know a document in the MySQL in the www.mysql.com web site, that would be sufficient.

Thank you.

Regards,

Eliot Lee
Quote Reply
Re: Resume Database In reply to
Karen,

In Reply To:
File upload would be a definite - common file formats, Word Docs for example. Pugdog, I'm not so sure on uploading the file into the SQL table, it would seem much easier for maintenance, troubleshooting, any sort of manual intervention to have the files actually uploaded to the server and use the script to call the file.
Again, like I stated, this would be tricky since you would have to password protect a folder via .htaccess to protect it from regular non-paid employers or users from accessing the files.

What you could probably do is the following:

1) Create a top-level folder called Resumes. Password Protect it via .htaccess and allow access for all paid employers.

2) Then you would have to create individual folders for each JOB SEEKER where their RESUME would be stored. Password protect it so that the employers and JOB SEEKER could the resume.

Again, if you decide to upload files directly to folder(s) in your server, it would be complicated to set-up the proper security. I believe that pugdog's suggestion for uploading directly to a database is much better since you can control access more efficiently and effectively.

Regards,

Eliot Lee
Quote Reply
Re: Resume Database In reply to
Thanks for the feedback Eliot. Why couldn't the files be uploaded to a location that is outside the web root directory and called via script?

Say the directory structure is:

/www/htdocs
/www/cgi-bin

Where htdocs is the location of the server's web directory. Why couldn't another folder be utilized outside of the web directory:

/www/htdocs
/www/cgi-bin
/www/uploads

And then use that directory to store the resume documents causing access to be available only via the scripts?

Thanks!

Karen

Quote Reply
Re: Resume Database In reply to
Because that folder needs to be WEB ACCESSIBLE if you are going to ALLOW PAID EMPLOYERS to DOWNLOAD the resumes. Sure, you could put it another folder below your WEBROOT, but then you would have to make an alias for that folder, so that EMPLOYERS and the RESUME OWNER can view the resumes!

Regards,

Eliot Lee
Quote Reply
Re: Resume Database In reply to
Eliot, I am lost on your description of the process. Even within the MySQL tables, the actual data is stored outside of the web level, scripting allows for the content to be delivered to the web.

By using the scripting to control access - Job Seekers able to add/remove the file and Employers able to view the files with limitations, the web access is controlled and does not need additional web aliasing, the path should only need to be valid within the scripts being accessed via the web. Much the same way as declaring the path to sendmail or db.cgi

I don't understand what you are saying in the actual files needing to be stored at the web level.




Quote Reply
Re: Resume Database In reply to
Because if you provide LINKS to "download" the files and they are NOT in a web accessible folder with no alias, guess what? They cannot download the files.....

Regards,

Eliot Lee
Quote Reply
Re: Resume Database In reply to
Forget .htaccess!!!! :)

Nobody uses that any more for customers, or surfers. It's ok for admins, or for adult sites, or to lock out a membership area, such as a forum, but it has problems.

Use scripts.

Once the user is authenticated, the script will run, and present the data. If not authenticated, the script won't present the data.

.htaccess is a problem, because all you are allowed is "basic" authorization, and you can't encrypt or do advanced checking (unless you run a secure server, https://)

Resume data is "confidential" to a large degree. You would want to probably keep track at who is looking at what, and who is accessing what. You certainly would not want to put that data in the document tree! It's just too easy to have a problem with it.

Also, you want to have _TEXT_ resumes, with maybe html formatting, not word.doc files. Those cannot be viewed on the web by most people. They cannot be searched by the SQL engine, and they simply take up space, with no benefit. If someone wants a printed resume, allow them to print a plain-text "pre" formatted copy. They can also contact the person directly to get a "professionally printed" resume, but that won't happen often.

I'll post another message on the storing files in MySQL after this.



PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
Quote Reply
Re: Resume Database In reply to
Yes, use BLOB and TEXT fields.

http://www.mysql.com/doc/B/L/BLOB.html

What you do, is use the upload function in the browser (multipart) to upload the data (or use simple form tags to capture it) and then insert the data into a mysql record.

Many banner/advertising services do that, storing the binary logos/ads in the database itself. It makes for a cleaner disk, at the cost of having to pump the binary data out and flag it properly.

In uploading a file, just take the variable you store it in, and assign it to a MYSQL field, rather than output to a disk file.

I would _strongly_ suggest a resume database stick with text files, but if you really want people to be able to upload their resumes, you'd want to figure out how you will do it. If they are zip or doc format, they can't be read on-line by most people.

I'm trying to finish up the multiple file upload module, and when it's done, it could be used to attach the graphics to the resume's html file. But, again, there are security and other problems with allowing people to upload random data.

I _strongly_ urge you both to think about using text fields, and maybe seeing how the big boys like Monster.com and Thingamajob.com do it.

There are lots of benefits, including security advantages.



PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
Quote Reply
Re: Resume Database In reply to
pugdog,

Thanks for your reply...

Actually, "big boys" (like hotjobs.com) allow you to upload .doc, .pdf, and other file formats. Monster.com does not have a file upload feature...you have to fill out series of forms. So, it would be neat to find a solution like hotjobs.com and others that allow uploading files in multiple formats and then allow specific users the ability to read data from those "files".

Thanks again for the clarification about uploading files directly into MySQL, I really appreciate it...it may also help me at my "real job" to make accessing our MBA resumes and Faculty CVs more secure...however, I will have to beef up my knowledge on MSSQL, since we are a Windows 2000 shop.

Yet we will have to re-write our Cold Fusion verity collection search scripts to parse data directly from the database rather than individual files...

Another question....

WHAT about RTF format??? How does MySQL handle Rich Text Format documents???

Also, what do you think about EXPORT features??? I was thinking of allowing employers to EXPORT multiple "resumes" into an EXCEL spreadsheet or possible as a MS WORD mail merge document. I know that I will have to edit the EXPORT subs in LINKS SQL to support different CONTENT/TYPE headers.

Regards,

Eliot Lee
Quote Reply
Re: Resume Database In reply to
more later, but

In Reply To:
Actually, "big boys" (like hotjobs.com) allow you to upload .doc, .pdf, and other file formats. Monster.com does not have a file upload feature...you have to fill out series of forms. So, it would be neat to find a solution like hotjobs.com and others that allow uploading files in multiple formats and then allow specific users the ability to read data from those "files".
Several problems.

1) again, how do you access the information in the resume on-line? Does the user type it in again? That means the resume may not match the on-line information.

2) while .pdf can be sent to a browser, I find that extremely annoying, and I have a fast machine, with lots of ram. Usually, especially for 1 or two pages of text, this is flat out pointless,and I can see more in my browser window. PDF has a place -- manuals and documents of some length with embedded images or charts. For a resume, from a jobs search, it's over kill, and pointless. The prettiest resume isn't going to win. The best indexed, searchable, and appropriate will.

BTW... I just took a look at hotjobs, one I hadn't visited before, and the areas I could get into were all text based. The jobs available, (had a printer friendly button, as I said), the post your resume asked for text fields, and prompted for cut/pasted from another document.

Their log on was extremely confusing, and didn't work, so I couldn't get past the first screen to post.



PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
Quote Reply
Re: [pugdog] Resume Database In reply to
Did you actually get this up and running ?
>> Nakul Goyal (SEO, Link Building Expert)
Web Site Promotion
Tips 'n' Tricks
SEO News