Luis Carlos,

> So, the 125 billions comparisons WILL BE MADE because i have no idea

right

> now how brushes are similar.

Actually, that is not true!

As you have already set there properties which brushes *must* share in
order to be even considered similar, so similarity need only be
calculated for those brushes which have those common properties.

These required properties can be defined into a compound index, which
would only return the target brushes.

> Doing in real time like you said i think is not possible because 200
> clients will be accessing the records at the same time. Doing the

calculus

> for each one will take more than 3 seconds. They do not want more than

3

> seconds to see the results. Take in mind that this is a system that

will

> be able to identify competitor brushes and my company brushes in a

quick

> way, when the client is still on the phone. That is the objective of

the

> project. So, 200 clients asking results to the system and each one

needs a

> result in less than 3 seconds!

I believe that you are over-estimating the 3 seconds of time to
calculate the results. Especially if you consider the required common
properties, which will significantly reduce the brushes to be evaluated.

(Confirming, you did say that the table of brushes would contain 500,000
items, right?)

Also, while you may have 200 clients connected to the database, I can't
believe that they all will be searching for matches simultaneously.

> So, doing a prematched table (billions entries) would resolve my

problem

> of 3 seconds to show the result. If there is a competitor brush

similar

> with our company, the result will appear in less than 3 seconds. Now,

i am

> not quite sure if this is the best solution.

I don't believe that it is.

> The system has a search criteria that is filled by the user. With this
> search criteria i find that possible brushes index in the brush

database.

> After finding those indexes, i search similarities in the my database.

Is there any way to perform the similar-to search by looking for an
exact match based on all the properties, and then dropping the match
criteria based on an order of properties which have the least relevance
for similarity.

After all, you are looking for candidates which have the greatest
similarity... not items which have a nominal similarity.

> Well, in fact i did not do it in real time to see how much time it

takes

> because right no i am working on the GUI. I am not ready with this

yet. If

> the times is quick reasonable it will be excellent. Its sounds stupid
> create a table with billions of entries, but i am trying to think the

best

> solution to increase the speed.

Creating billions of entries is not a way to go.


Sean