I would say store documents in the file system as you normally would and store the document heirarchy in the database. I had a similar situation while building a school content management system where different courses could have several documents, images videos etc associated with them. what we end up doing was to save every document saved with a name as UUID in one folder and let the database handle relationship among them.
just my 0.02 cents On 2/10/06, Pete Ruckelshaus <[EMAIL PROTECTED]> wrote: > > I have stored docs in Oracle. It simplified matters for us because we > had an enterprise-level database and a clustered server environment; > having to sync portions of the filesystem would have added unwanted > complexity to the system. > > I suppose how you store your contracts depends upon what you need to > do with them. Do users need to have regular access to them? Is it > for archival purposes? Do the docs need to be searchable? > > Since it seems like you need this more for archival purposes, I would > personally store them in the database, assuming your disk space and > backup capacity would cover it. That way, you have much tighter > control over who accesses the documents, which I would assume would be > a concern. > > You'll probably get a dozen answers on this, all different. > > Pete > > On 2/10/06, Michael T. Tangorre <[EMAIL PROTECTED]> wrote: > > I have never stored actual documents in SQL Server. I have stored the > name > > and location and put the document into a directory on the file server. > > However, a new "contracts" application I am working on is very document > > heavy, mainly for storage... not much retrieval will be done. > > > > Currently when a new contract comes to be, a directory is created for > the > > contract and a slew of sub directories are also created over the life of > the > > contract. Sometimes the sub directories are standard across contracts > and > > some times they are not. Sub directories can get pretty deep in terms of > > nesting. > > > > It seems it would be much easier (conceptually) to store the documents > > directly in the database and let the structure of the database dictate > the > > "hierarchy" and relationships instead of creating a new directory for > each > > contract and trying to figure out which subdirectories are needed or > already > > exist, etc. > > > > When needed, the documents would be accessed via the application... > however > > this would restrict direct access to the document outside the system. > > Anyway, has anyone taken the approach of storing documents directly in a > SQL > > DB, and if so, how was performance etc... > > > > Thanks! > > > > Tango > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:231947 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
