Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
kansascoder
Starting Member
3 Posts |
 Posted - 2008-09-08 : 09:49:51
|
| Hi,The company I work for (a nonprofit which is a late comer to the electronic enterprise) recently built an intranet in .net 2.0 using sql server 2000 (enterprise) as its back end. Part of its content are the companies Policies and Procedures, 2 seperate documents organized in typical hierarchical/outline fashion. Currently the individual responsible for maintaining these documents saves Word docs as html files and copies them to a directory on our intranet server. Users (about 500 total not all on the intranet at once thankfully) can then select a section of the document for display but are not able to search the documents.I was thinking that storing these documents in a SQL Server database would be a good way to maintain the docs, allowing for version control when updates are necessary (not currently being done). This would also allow users to do a better search.. at least better than the current ctrl-f they do once they've found a page that looks like it might contain the information they need.Additionally, we would like to use our intranet as an interface for editing these policies. Occasionally an insert needs to be made and so a database seems a good choice.I have not found any articles talking about doing this so I'm wondering if I am way out in left field here. Should I be looking at an open source document management system rather than a homegrown relational database solution? I've not because it seems overkill for 2 documents. Would a pure xml solution be best? I've not gone there because no one here is proficient in xml querying. Any insights would be greatly appreciated! |
|
|
Sitka
Aged Yak Warrior
571 Posts |
Posted - 2008-09-09 : 11:22:21
|
| Set up a wik,i Screwturn is free, is super easy to get running.Full text search and complete versioning/rollback. You may want to customize it a little since it's pretty bland. Don't underestimate how badly that individualwill want to continue using Word."it's definitely useless and maybe harmful". |
 |
|
|
kansascoder
Starting Member
3 Posts |
Posted - 2008-09-09 : 12:54:35
|
| No doubt the one administrator will want to keep using Word but fortunately the ultimate decision making power lies elsewhere. I'm going to put a wiki on my list of possible solutions and ScrewTurn looks like a nice product. Since these are corporate policies we would lock all the pages and allow only administrators to edit the content. I like that previous versions are stored automatically upon editing a page.I spoke with a colleague who maintains their corporate policies in a sql database and allows the content to be editable. Since we have 4 documents to maintain, each less than 200 pages in printed material, I'm thinking that saving the documents in tables with subsections having their own record and a parent child/indicator field like policyID (is it employee or corporate policy, ie. 1)Policy_number (specific policy item, ie 02)section_number(entry in policy item, can mbe multipl, ie 05)This way I can get to specific areas of the document for editing, be able to save the previous policy section version without having to save the entire policy each time a change is made. I think saving a version to xml for display is overkill and I will probably just display the policy from the table as it is called up by the user form our intranet's gui. |
|
|
|
Sitka
Aged Yak Warrior
571 Posts |
Posted - 2008-09-10 : 08:31:37
|
| Another way is to save the whole document as an image, like Sharepoint does, but upon each update write the previous version to an audit table, same as application facts tablebut with a couple extra columns like version/changedate/user. Lots of people do this. I've never built and application yo do this because it gets exploited (huge files.).With Sharepoint you can often justify it because the Sharepoint server is scoped and maybe dedicated to that type of file handling.Taking a small department/functional application onto a multipurpose server and then that application gets lots of use(good), lots of large image fields, but that might beoutside the scope(bad) of the planned growth performance and can cause a larger than necessary administrative burden. Still a relatively Simple way to do stuff, andthe Terraserver project was the test for just how huge an Image handling MSSQL DB can be. retty big to put it mildly. "it's definitely useless and maybe harmful". |
|
|
|
Sitka
Aged Yak Warrior
571 Posts |
Posted - 2008-09-10 : 08:31:38
|
| Another way is to save the whole document as an image, like Sharepoint does, but upon each update write the previous version to an audit table, same as application facts tablebut with a couple extra columns like version/changedate/user. Lots of people do this. I've never built and application yo do this because it gets exploited (huge files.).With Sharepoint you can often justify it because the Sharepoint server is scoped and maybe dedicated to that type of file handling.Taking a small department/functional application onto a multipurpose server and then that application gets lots of use(good), lots of large image fields, but that might beoutside the scope(bad) of the planned growth performance and can cause a larger than necessary administrative burden. Still a relatively Simple way to do stuff, andthe Terraserver project was the test for just how huge an Image handling MSSQL DB can be. retty big to put it mildly. "it's definitely useless and maybe harmful". |
|
|
|
|
|
|
|
|
How best to work with Hierarchical Data