View Single Post
  #15  
Old 05-18-2008, 02:49 AM
ashwken ashwken is offline
Registered User
 
Join Date: 10-16-2005
Location: Blairsville, GA USA
Posts: 431
Re: Re: Re: Re: Same planet, different world

Quote:
Originally posted by quant
ok, just for the sake of discussing different approaches:

So the databases could be merged to a single one (where one can easily limit searches to only a part of database if desired). And with favourites and hoisting, it could really feel like you have two databases in a single file. Plus, if there are some things which are common, these could be connected (multiparenting) and promote understanding.

You say there is enough difference to keep them separate. Why would this "enough difference" imply keeping them separate? Are there completely different templates used for the similar things that would cause confusion?

Or is there a speed issue? DB file too big for OS to handle? Or some other compelling reasons? ;-)
Thanks for forcing me to think this thing thru.

The example that I used was not a good example in support of needing Search across Multiple DB, but a good example of poor initial design. Yes, these two databases will be merged at some point.

Part of what I was trying to show (poorly) were some of the "pitfalls" that reveal themselves down the road. You start out thinking that two things are disimilar enough to warrant separate databases, but over time and with the assemblge of data the similarities begin to show - as evidenced by the requirement to search more than one db for a thing.

Let's try a different case for Multiple db Search.

I've got a db for Lead Tracking which contains default Contact records and history of interaction.

I've got another db for Transactions Listing / Sales Tracking which contains custom Contact and other forms.

Although both databases have the common element of being related to my work (and being somewhat Contact centric), are they disimilar enough in purpose to warrant separation?

In the Lead Tracking db the history of interaction consists a lot of email (and attachments plus other contact events), this db is getting pretty big.

A Lead (Contact record and history) can advance to the state of being a Customer or Client (enter into a Listing or Sale Transaction), and also become a Prospect for a new Transaction at a later date.

This seems to indicate that a Lead should remain in the Lead Tracking db and not be phyiscally moved simply because it has entered into a Transaction.

But at some point you are going to want to see the complete picture of your dealings with a Contact, the complete picture resides in two separate databases.

You can create a link (copy w/url, paste to rtf) between the corresponding Contact records upon the first instance of a Lead taking part in a Transaction - each record would require a link to the other.

Would the result of a Search across both databases yeild a better picture?

Maybe hashing this stuff out will help identify db design considerations.
Reply With Quote