On Apr 08, Giuseppe Corbelli <[EMAIL PROTECTED]> wrote:
> The usage performance is more important, isn't it?
Absolutely! And database independence is a benefit that compensates
even a noticeable slow down at insert time.
Having said that, 5 or 6 hours to complete are a very long time, and
I hope
On Fri, Apr 07, 2006 at 05:26:43PM +0200, Davide Alberani wrote:
...
> > I'm also open minded to to write a little benchmark, for checking
> > both approaches, which is the more promising one.
>
> I think there will be a lot to test, in the future; I fear that
> the switch to SQLObject and the su
On Apr 07, Martin Kirst <[EMAIL PROTECTED]> wrote:
> >On the other side, I think that at _usage_ time, performances
> >won't be greatly affected (maybe no more than 1.2x or 1.5x)
>
> Are all SOUNDEX - values in this style/syntax?
Yes, they are. Some algorithms will output an upper char
followed
Hi There!
I fear I've not expressed myself clearly (Pardon! Even my Klingon is
better than my English... ;-)
Don't know about your Klingon, but your English is very good.
And maybe, sometimes I should read e-mails with more care ;-)
[... good explanation about SOUNDEX ...]
I believe, that
On Apr 06, Martin Kirst <[EMAIL PROTECTED]> wrote:
> Hello everybody!
Hi!
> I think it is not a good idea to pre calculate all the combinations
> of a movie title (person name and so on) which are possible.
I fear I've not expressed myself clearly (Pardon! Even my Klingon is
better than my Eng
Hello everybody!
While I was reading the last devel-mails there was something
that came to my mind about the SOUNDEX feature.
I think it is not a good idea to pre calculate all the combinations
of a movie title (person name and so on) which are possible.
Because of, If we assume 10.000 movie tit
6 matches
Mail list logo