What about this:

Instead of putting large texts in table A, you add an integer that points to
table B, which contains the texts. This way, you can reduce the number of
texts in the system, saving space.

In order to find out, if the text already exists in table B, you would do it
like this:

select textid from texttable where text=...

If the texts can be larger than 4096 bytes, such an index would be useful.

I have such a system in one of my databases for log texts. Logs tend to
repeat the same text again and again, and are normally very large in size.

Med venlig hilsen – Mit freundlichen Grüßen – Best regards

Lars B. Dybdahl





_____

Fra: Firebird-Architect@yahoogroups.com
[mailto:Firebird-Architect@yahoogroups.com] På vegne af Leyne, Sean
Sendt: 7. juli 2006 23:59
Til: Firebird-Architect@yahoogroups.com
Emne: RE: [Firebird-Architect] Indexes for big objects



Ann,

> The index itself would be a standard btree using the hash
> as the value. It would be useless for returning records
> in sorted order - but good for retrieval and unique
> constraints. From the application perspective, there would
> be no difference in definition - just removing the limit on
> the length of the key.
>
> Thoughts?

I don't see the value of this type of index, expect to handle
uniqueness.

By even then, now with an index that can be up to 4096 bytes in size,
how realistic is it need an even larger key?

Maybe I'm looking at this to narrowly... can you give an example that
might help me 'see the light'?

Sean






[Non-text portions of this message have been removed]