Quote:
Originally posted by quant
I'm not sure I was convinced. What is the decisive "thing" in this case that made you split it into two databases as opposed to just being two different directories in the same db?
|
Part of it is that the databases have been created and developed at different times, evolving under my learning curve (of both UR and my workflow) and the evolving capabilities of UR.
Another part of it stems from the (growing) size of the Lead Tracking db, and later the Transactions db (may be a workflow problem in both cases). Size relates to both operational performance (possibly subjective) and backup (originally restricted to CD media, change to other media is now possible).
The Lead Tracking db uses the default UR Contact record to accept a Contact from Outlook. An Outlook record is built for each Lead that comes in. The record in Outlook needs to exist so that I can email from the Multiple Listing Service (MLS) program. This Outlook record is pretty much the master.
The Lead Tracking db has various folders that represent different stages of interaction with the Contact. For example, when initally sending a Contact record from Outlook to UR, there are a number of target folders that correspond to the source type of the Lead (a number of specific pubs, our website, other), the Default Child Item for each of these folders contains distinct default data.
This Default Child Item is a Folder that is entitled with the name of the Contact, the contact record is moved to a child of this Contact Name folder. Its Default Child Item is a Contact Event Folder which will contain the various things that constitute the Event (emails and such, or the Detail Pane could be text notes of the event with no children).
\Lead Source Type\new Contact Item
\Lead Source Type\Contact Name Folder
\Lead Source Type\Contact Name\Contact Item
\Lead Source Type\Contact Name\(date) Event
\Lead Source Type\Contact Name\(date) Event\email
The continued growth of this db is directly related to my workflow of moving the relavent emails from Outlook into UR. In many instances these emails contain sizable attachments (images, pdfs, ...). This may be a case of improper workflow (design decesion) - perhaps it would be better to manage these emails within Outlook (moving them to a separate pst), then link/sync them from UR (which is the more reliable format, pst or urd).
Another area that may need to be re-examined is the use of the Contact Name folder. This was originally utilized to track user defined Attributes in UR, it now may be the case where these Attributes can be created in Outlook and "carried thru" to UR, eliminating the need for the Contact Name Folder. Or maybe I'm not fully utilizing Outlook Categories and how they translate to UR keywords.
After the initial response (Contact Event) to the new Lead, the Contact Name folder is moved to another Folder that correspondes to a level of activity - Lead Processed (waiting for some response), Link Accessed (a weblink within an email has been accessed), Working (on-going interaction), Inactive (Removed-Bad Info).
\Lead Source Type\
\Lead - Processed\Contact Name\
\Lead - Link Accessed\Contact Name\
\Lead - Working\Contact Name\
\Lead - Inactive\Contact Name\
This part of the workflow seems to be a toss-up between physically managing the differnt aspects of Lead interaction (represented by the folder structure), or "flattening-out" the tree and managing the Lead interaction with a UR Attribute and pre-defined Searches (hoisitng, favorites).
==========
The Transaction (Listing / Sales) Tracking db takes a slightly different tact in dealing with Contacts. Here I'm having to use a Custom Contact Form due to needing more Contact fields than are recognized by UR from Outlook. And I'm having to create individual Contact records for each person. This is a modeling requirement - a person can enter into a Transaction as an individual or as part of a group (depends on how the Deed is made out). I've also got a custom Contact Form for Vendors.
For a Listing there are various supporting docs (emails, pdfs, word docs,...) that are linked or stored in the db. A Listing also requires additional tables (tree branch) that deal with Adv Tracking (both specific to a Lisitng and generic for the Firm), Lockbox Tracking, and Signage.
For a Sale there are the various supporting docs and such.
This db is also growing in size due to the storage of emails (and their attachments), again could be a workflow problem.
Listing and Sale transactions remain in the db even after completion.
Quote:
Originally posted by quant
I probably don't understand all details, but from the database design point of view, all these seems to me like a perfect example for just having different tables in the same database.
|
This is probably more detail than you wanted, but talking this thing thru may be of benefit. I can see where you are coming from, unfortunately the choices we make are based on our understandings at the time. I'm not sure if I've made a convincing case or simply revealed areas in my work that need addressing.