Searching across linked databases

[tfjern]

I searched the forums, but couldn't find an answer to this question: if two or more databases can be linked, is it possible to search (say for specific words) across databases?

[ashwken]

I'm pretty sure that it can't be done yet.

See Road Map - Approximate Priority for Future Releases, towards bottom of list:

http://www.kinook.com/Forum/showthre...?threadid=3204

[tfjern]

Thanks for the link. I guess that would be Multi-DB searches, which is scheduled for "future releases." Judging from the usual wait between releases, this would probably mean years from now. Am I right, kinook?

[armsys]

Hi tfjern,
Have you ever thought of the cons of multiple URD search?
Instead of getting some 200 hits, you may wait for 2,000 hits or more, resulting into more noise than high value matches. Just my 2 cents.
Armstrong

[tfjern]

The search function in Ultra Recall is, well, less than robust (a topic that has been discussed several times before). I've tested almost every similar program, from AskSam to OneNote, and abandoned them out of disappointment (e.g., AskSam too buggy, OneNote too slow, TheBrain -- too huh?, etc.).

But I'm still with Ultra Recall, despite its less than spectacular search function (I'm tiptoeing because I like the product, and I don't want to focus too much on a negative, but Ultra RECALL is designed to RECALL stored data, isn't it?).

I realize that I could end up with thousands of hits when searching over multiple databases, but how else am I supposed to find something in a huge pile of information that I've accumulated? You may ask, why use multiple databases in the first place? Just dump everything into one? But I can foresee that I am going to reach a point where I have too much data stored in one file. It would be nice to be able to link several databases with a global search function. I realize there are several third-party software options available, but...

Anyway, Ultra Recall is about as good a product as we are going to get for some time to come, so I for one am going to support it as much as I can, and hope that a global search function will be included in future versions. I guess it's already on the road map.

Say, isn't 3.5 supposed to be out by now?

[ashwken]

Originally posted by tfjern
Say, isn't 3.5 supposed to be out by now?

Send support an email requesting the url for the beta download, latest beta 05-15-2008 - not sure when it's moving out of beta.

I also work with many UR databases, but these are somewhat segragated by topic or focus so there's little overlap.

For those instances where you have the need to search more than one db perhaps the overlap is an indication of common ground between the databases.

You could always do a periodic merge of the diffierent databases if you find yourself needing to constantly search the same ones individually.

'Course none of this compares to your original request.

[quant]

Originally posted by ashwken
For those instances where you have the need to search more than one db perhaps the overlap is an indication of common ground between the databases.

I'm with ashwken on this. It's kind of contradicting - you create more db's because you think they should be separate, and then you are trying to search and find sth in more that one db on a given topic, or whatever?

I'd prefer if the contents of UR files were searchable by (lets face it, much more powerful) third party tools ...

[tfjern]

Well, in the real world things aren't as meticulously organized as the planet some beings apparently inhabit, and a global search engine could be a useful tool in UR (why else would it be on the road map?).

There is so much information to store, and so little time to organize it, only the obsessively organized or well-disciplined can keep everything together. So for us lesser mortals we need all the help we can get, so could you give us some slack for once?

Geek said he was with ashwken on this, but ashwken himself works with "many UR databases." So what is the "this" that Geek is with?

[armsys]

Geek said he was with ashwken on this, but ashwken himself works with "many UR databases." So what is the "this" that Geek is with?

Ashwken is the known UR guru enjoying multiple URDs.
tfjern, perhaps you misunderstood Quant's intent. Quant just illuminates the view that Ashwken isn't a big fan of multi URD search. But I could be wrong.
Armstrong

[ashwken]

Originally posted by armsys
Ashwken is the known UR guru enjoying multiple URDs.
...that Ashwken isn't a big fan of multi URD search.

Thanks for the compliment, but it's way overstated.

Search across Mulitple URDs would be benefical in many circumstances.

Part of the reason I end up with multiple URDs is that I tend to push the database aspect of UR (probably) more than the authors intended.

For example, I have one URD for cataloging music - granted there are many good music catalog programs available, but none that allowed me the depth and customization that UR allows. 'Course there are some features available in specific music catalog applications that I can't duplicate in UR, but I've been able to accept these deficencies and found work arounds.

Another example is a URD for cataloging and researching the works of a specific author, and the spin-offs that his work inspired.

An example of overlap could be found in a URD I have for Current Events, and a separate URD for Run Up to War. Both of these URDs are more research oriented, as opposed to cataloging, and as such could benefit from multiple db search. An arguement could be made to merge these two databases since there is some intersection of purpose, but on the other hand there is enough difference to keep them separate (Current Events is more general, where Run Up to War is more focused).

The flexibility that UR allows is both powerful and frustrating, and I really enjoy learning how others are putting the program to use.

[quant]

Originally posted by ashwken
An example of overlap could be found in a URD I have for Current Events, and a separate URD for Run Up to War. Both of these URDs are more research oriented, as opposed to cataloging, and as such could benefit from multiple db search. An arguement could be made to merge these two databases since there is some intersection of purpose, but on the other hand there is enough difference to keep them separate (Current Events is more general, where Run Up to War is more focused)

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? ;-)

[armsys]

Hi tfjern,
If you have to deal with a huge number of URDs, you may find the Database toolbar (hidden by default) immensely useful. It's more efficient than pressing F6.
Armstrong

[armsys]

Hi tfjern,
For multiple URDs, you can hyperlink any items such as folders, appintments, contacts and documents across multiple URDs. For details, see http://www.kinook.com/UltraRecall/Ma...allinking.htm.
Armstrong

[tfjern]

Thanks, armsys. Finally, some constructive help.

[ashwken]

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.