Setting up a knowledgebase

[kathryn]

Good morning, all.

I have just been assigned a project to set up a company wide knowledge base and I am soliciting ideas, references, warnings, and resources.

We will be using SQL Server for the database.

There will be a user portion of the site and an admin portion.

From the user portion we will have the following functionality:

Search for all or any search terms using the keywords associated with each article (many-to-many).
Write a record to a log file if the search returns 0 records to be used to analyze needs for new articles.
Display "Did this help you?" radio buttons and comment textarea at the bottom of each article.
Store results from "Did this help you?" radio buttons and comment textarea in a table.
Store the number of times each article is viewed.

From the admin portion, we will have the following functionality:

Add new articles.
Assign keywords to articles.
Add new keywords.
Edit articles.
Delete articles.

Any thoughts on the above? Is it a good idea to assign keywords to each article, or is it better to just query the actual Title and/or Body for the search words?

I know that there is a CF tag to do this, but we are in a spending freeze right now, so we can't spend ANY money. Therefore, I am reinventing the wheel...or rather I will invent the wheel once our development servers are cleaned of this *^(*%&% virus and made available to us!

Any thoughts would be greatly appreciated.

Kathryn

 

[calista]

Well, kathryn, I was hoping one of the gurus on this site would respond to you, but for the moment, anyway, you're stuck with me. I am working on a similar project, I think. I have been building an intranet for the primary purpose of providing online access to documentation for a group of software engineers. You've asked a big question, so I'll answer what I can.

By your presence in this forum, I assume you have Cold Fusion.

Like you, my documents have a many-to-many relationship to the products. I dealt with this by creating 3 tables, a Document Table, a Product Table, and a ProductDocument Table. Each individual document has an ID as the primary key, and each product has an ID as a primary key. The third table links them together by using the document ID and the product ID as a combined key.

As far as searching goes, CF come with a Verity search engine. How you should go about this depends somewhat on how long these articles are. For example, I have a search function on my discussion board. The entire message is stored in the database since they tend to be fairly short. CF and Verity can index the results of a query, so that is a reletively simple process. On my larger documents, I do the same thing, except all I store in the database is the title, a description, and the file name, and a few other pieces of information, and I can query for title and description and run my search on that. I am in the process of implementing a full text search function, so stay tuned!

I haven't dealt with log files, but when you run a query, a record count is returned, so it seems easy enough to write a message to a database if that number is 0.

To display everything, I use nested tables. This will enable you to diplay the article and the form you want at the bottom.

I also haven't tried to keep track of page hits, but it seems like when the user finally clicks on the article he wants, I know what the document ID is at that point, so I could write that information to a table.

The admin portion is a matter of creating forms, processing the information, and storing it in the database. You'll, of course, be implementing some form of security. If only a few people should have access to the admin portion, and those won't change very often, you could get by with hardcoding their IDs, but there are better ways to do that. Search this forum for security and/or user authentcation, and that should give you some ideas for that.

Hope I haven't bored you and this was useful to you. I'll be happy to go into greater detail if you want. Too bad about that virus. Those people should be exiled on a desert island with no electronics, AFTER they have restored your system. Good luck!

Calista :-X
Jedi Knight,
Champion of the Force

 

[kathryn]

Thanks so much for the reply.

I have been reading up on Verity using Ben Forta's book and I see that you can get it to search a database (which I didn't know), so that is the way I am going to go: CF, SQL Server and Verity.

The boss likes my specs, which are similar to the description I gave above, except without the keywords, so I am off and running.

I'm sure we'll "see" each other again, since I will probably be doing some more posting as this project develops.

Thanks again. Kathryn

 

[ianholmes]

Hi kathryn / calista

I too have been asked to spec. a system similar to the ones you have been describing.
I note that this thread started last September.
How did your projects go ?
Can you give me some advice as to how best I should proceed in specifying such a system ?
Are there any prototype documents available on the web that I can use as a basis ?
Hope you can help.
Regards

 

[calista]

Hi, Ian!

My project went fine. Unfortunately, I got laid off about 6 months ago. :-( Anyway, I did eventually implement a full text search for my documents. The key to making that work in CF was to make sure "Document Properties" were filled out. Most people don't do that when they're creating a document, so I had to go through over 400 documents and fill them in. I also converted some to PDFs so the user wouldn't have to have the software that created the original document in order to view it. If you can be a little more specific in your request, maybe we can help you better. Let us know how it's going! Calista :-X
Jedi Knight,
Champion of the Force

 

[webmigit]

Hey Calista, welcome back Haven't seen your light sabre battling off the evil ungeekiness in a long time..

(What'd you think of Attack of the Clones? I thought Phantom Menace was much better... However AotC had Yoda, the weedeater from He--ck. Hilarious.)

Anyway Ian.. Calista's thoughts ring true but one bit of advice on the search.. always best to use full search capabilities.. Search is there to benefit the user and they may be searching for a specific word or phrase, something your description may not have...

For instance.. John Doe may write a post comparing computers..

The contents?

"I had an HP for a while but then I moved to Dell... The Dell was overexerted on simple tasks, but I found the computer I got from the little guy here in town moves fast enough for me.."

The description would read something like...

"John rates his experience with different brands of computers."

Since the data is already in your db a quick search would work well.. you may even limit the number of keywords.. provide for instance two or three text boxes..

Ah, and one more tip.. I don't know how other users rate this method but I like to centralize my code, IE, Adman and regular users need access to changing their passwords... They should both have the same profiles so rather than create an admin section, I have a field in my users table simply called admin.. then I check in a cf with something like...

<CFIF AccessQuery.Admin eq 1>
show admin links
</CFIF>

And I wrap all admin pages in that, the top and bottom line are the beginning and conclusion to that cfif statement..

Sure you can as easily hold the data in two different tables and two different member sections but that means a lot of taks will have to be done twice, and that can get vey frustrating...

Tony ALFII.com

http://www.alfii.com

---------------------
If this post answered or helped to answer your question, please reply with such so that forum members with a similar question will know to use this advice.