Subject | Re: [firebird-support] Re: unsuccessful metadata update, key size too big for index |
---|---|
Author | Helen Borrie |
Post date | 2004-02-05T13:11:05Z |
At 12:57 PM 5/02/2004 +0000, you wrote:
limit on the size (width) of any index. The limit is 253 BYTES (not
characters). So, if you have a VARCHAR or a CHAR of 100 UNICODE_FSS
characters, it is too large to index.
To index those columns, you would have to reduce their size to VARCHAR(84)
or less. CHAR is not a good type for variable data or for wide indexes,
because it pads the data out to full width.
Breaking up the tables makes *NO* difference. The index width limits would
still apply.
FYI, the reason why constraints come into the picture is that the engine
automatically creates indexes to enforce them (PRIMARY KEY, FOREIGN KEY and
UNIQUE). So you can't define one of these constraints on any UNICODE_FSS
column of 100 characters ( = 300 bytes).
/heLen
>Ah, no, I meant: if I break up this table into multiple tables, eachNo, you haven't got it straight yet. It is not the constraints, it is the
>would only *require* two constrainst max, and that that could maybe
>fall within the 255 bytes limit (as inconvenient this setup may be).
limit on the size (width) of any index. The limit is 253 BYTES (not
characters). So, if you have a VARCHAR or a CHAR of 100 UNICODE_FSS
characters, it is too large to index.
To index those columns, you would have to reduce their size to VARCHAR(84)
or less. CHAR is not a good type for variable data or for wide indexes,
because it pads the data out to full width.
Breaking up the tables makes *NO* difference. The index width limits would
still apply.
FYI, the reason why constraints come into the picture is that the engine
automatically creates indexes to enforce them (PRIMARY KEY, FOREIGN KEY and
UNIQUE). So you can't define one of these constraints on any UNICODE_FSS
column of 100 characters ( = 300 bytes).
/heLen