Hello cmo63126,
In early days of database development, it was common for the primary key of
a record to be derived from the values in the record. So, for example, the
ID of a customer John Smith who lives on 123 Main St may be JOSMI12X999 with
the last four characters used to create a unique id between this record an
the record of Joe Smart at 123 Elm.
It quickly became apparent that there's a problem with this: What happens
if John Smith moves from 123 Main to 765 Willow? Do you change his ID? and
doesn't that mean that you have to find all the records linked to his ID and
change them too?
You have created the EXACT same problem for yourself. You have tied the
location of the document to a variable value in a database record, which
means if the value changes, you have to change the location... and you are
paying for it by creating a needlessly complex design to cope.
Strong suggestion:
Do not place files in a fileshare that has anything at all to do with the
department. Create a tool for placing files in the site doc library.
First, get a unique and arbitrary value for the id of your document. (if it
is random, like a GUID, you can do interesting things like create
subdirectories based on parts of the ID). For simplicity sake, let's say
you put 100% of you files in a single "documents" folder on your site. Your
tool will rename the file to the ID (keep the extension), and place it into
the Documents folder. In your documents table, put in metadata, like the
original file name, date imported, and the user id of the document owner
(assuming you want to eventually find the document, or delete it, or replace
it with a new version).
Now, when the user changes the department of the news item, your document
doesn't move. You also get the advantage that a document cannot easily
overwrite another document because the name happens to be the same (common
in sales or marketing organizations, where most documents start with a
template).
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
<cm******@yahoo.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...
No it's not a concurrency-related issue. I have a news portion of my
web app. where each news article has the potential for a document
library associated with it. if the user creates a press release and
wants to upload related documentation, they have the ability to do so.
there's 3 areas that potentially must be modified when an article has
changed:
1. Articles Table: housing all data related to article itself
Fields include: (title, summary, body, opendate, closedate,
DepartmentName, DocLibraryID (see 2.), etc...
2. DocLibrary Table: housing all documents (if any) associated with a
given article.
Fields include: (ArticleID, FilePath, other irrelevant fields)
3. Physical Directory where docs are stored.
when the article is updated - I assuming it's the proper way of doing
so - I start my changes from the bottom up in steps 3-2-1 fashion.
I my example I need to check if the user has modified the article to
display under a different department or has changed its display date.
This will effect the physical path to the article's document library.
for example:
Original article: Created for "Public Relations" on January 31, 2005
path: /Docs/News/PublicRelations/2005_01_31/
Updated article: Moved to "General News" on April 15, 2005
new path: /Docs/News/GeneralNews/2005_04_15/