UdmSearch: Multiple subject tables

1999-11-07 Thread Eric Mings
Is it advisable or possible to maintain different tables (url) for indexing sites associated with different subject areas? I could create different databases for each subject types, but that seems very redundant in terms of having to have copies dictionaries, stop words etc in each database. T

Re: UdmSearch: Multiple subject tables

1999-11-08 Thread Alexander Barkov
Eric Mings wrote: > > Is it advisable or possible to maintain different tables (url) for > indexing sites associated with different subject areas? I could create > different databases for each subject types, but that seems very redundant > in terms of having to have copies dictionaries, stop word

Re: UdmSearch: Multiple subject tables

1999-11-08 Thread Eric Mings
> Hi! >You can use URL limitation to search in database part >as well as tag limitation. Just give different tag values for >URLs with different subjects. Check documentation for >further information about tag usage. Thanks! I think I understand this, but doesn't this just end up storing eve

Re: UdmSearch: Multiple subject tables

1999-11-12 Thread Eric Mings
I continue to wonder whether udmsearch can be modified to allow for multiple url tables to store information based upon a user criteria (such as storing different subsets of sites indexed) in a table of their choice. I understand the current ability to store tags in the single url table that

Re: UdmSearch: Multiple subject tables

1999-11-15 Thread Alexander Barkov
Hi! Eric Mings wrote: > > stored and searched). However the multiple database approach would result > in considerable duplication of information (such as dictionaries, > stopwords, etc). stopwords and ispell dictionaries are not so large. > It would seem that modifying the search pages to al

Re: UdmSearch: Multiple subject tables

1999-11-15 Thread Eric Mings
>I write it on our "feature requests list". But you should understand >lacks of such method. You will not be able to search though all of >the database parts in one SQL query (at least in databases without >UNION). >You see, it requires major modification of both indexing and searching >programs.