peter_jacobi.rm wrote:

>>The TikiWiki database has a lot of long keys because they use long
>>VARCHAR fields for Primary Keys.
>
> [...]
>
>>>Does anybody know if FB 1.5 solves this issue?
>>
>>Simply copying bad design may not actually be solving a problem just
>>perpetuating it ;)
>
> On a recent similiar discussion I proposed to cope
> with long strings which must be indexed, by using a
> loadable collation which replaces the tail of the string
> with a hash key:
>
> "A long string which is unwisely be choosen as primary key"
> =>
> "A long str {4DF543E5}"
>
> This will actually work, and would be invisible to the
> app (if sorting only on the first N chars is good enough),
> but of course it's a hack.

Again it's not the solution to the problem :)
It WOULD be nice to do UNIQUE on longer fields, so lengthening the
maximum key length is a good idea - unless we can do the check using the
real data ( In which case your idea would give a subset to work on ).

I was just trying to point out that it's the USE of long strings that
may actually be the problem in most of the cases ;)
MySQL designers have not had to worry about 'real' database design yet :)

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services