Subject RE: [firebird-support] Database design comments
Author Leyne, Sean
Luis Carlos,

> So, the 125 billions comparisons WILL BE MADE because i have no idea
> 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
> for each one will take more than 3 seconds. They do not want more than
> seconds to see the results. Take in mind that this is a system that
> be able to identify competitor brushes and my company brushes in a
> way, when the client is still on the phone. That is the objective of
> 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
> of 3 seconds to show the result. If there is a competitor brush
> 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
> 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
> 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
> solution to increase the speed.

Creating billions of entries is not a way to go.