Fill in the box below so we can keep you up-to-date with the latest best practices for winning more business.
Databases vs document management systems for proposal information
Companies with online resume and project summary resources tend to call them “data bases.” In most cases, they incorrectly use the term. A collection of files is not a database.
A relational database is a structure based on tables and a query language to extract data from the tables. Each row in a table is a record, and each column is a field. Databases work great when you can specifically define the fields in each record.
However, relational databases tend not to work well for some applications such as resumes. If you try to define fields for common resume items (summary, education, experience), you’ll find that picking the right granularity is difficult, and even if you manage to come up with a perfect field list, you’ll find the resumes you have don’t match. This leads to creating database forms and having everybody enter their data into the very specific forms. That’s a lot of programming. And then you have a problem going from the resume-as-table to the resume-as-document for the proposal.
Keeping the resumes as documents is probably better, but then your only search mechanism is keyword searching. Keyword search can be effective, but on resumes the same word in different sections takes on a completely different meaning. Keyword searching resumes is usually less than effective.
The same issues that have applied to the resume examples above also apply to project summaries, boilerplate, and other text-resources you may want to have for your proposals. Before committing to a true “database” development projects make sure you know what you’re getting into and that the data model you build actually fits the way you are going to be using the application.
Show the author of this article some love and appreciation by posting a link to it or emailing a friend and telling them about it. Thanks!
