Subject | Re: [firebird-support] Design for speed |
---|---|
Author | Lester Caine |
Post date | 2006-02-13T15:51:22Z |
Lester Caine wrote:
developers list :)
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
> I'm having a bit of a tiff with the postgres guys an bitweaver, so IThis too complex for the support list - should I try architecture or the
> thought I would check my facts here first :)
>
> All the content in bitweaver is stored in a single table, with blobs
> storing the actual content, and the rest of the fields containing
> management info. The user_id(INTEGER) replaces the 128 character name
> field from other designs, but we are still left with three 'guid'
> fields, two 16 character for type and format ( wiki-html, blog-text etc.
> ) and a new 32 character field for language.
>
> My gut reaction is that Firebird would be faster if these three fields
> were just INTEGER ( in fact a single byte would do since the three
> tables are only a couple of dozen types though language could get bigger
> ) This would reduce the record by 52 characters, but having to compare
> strings rather than a single integer is surely a slower process. I
> presume that the tables for the cross reference would life in memory, so
> JOIN to provide the text in the query result would be easy.
>
> The other point of discussion is the addition of fields for security and
> other management functions. These are currently being added as joined
> tables, on the basis that not all records need to have a group_id or
> source_id, but when looking at 100k items of content, all of which have
> these to fields filled in, I can't see how managing a separate
> content_id/group_id pair in a separate table gives you anything, and
> even if only 10k of the group_id fields were populated, surely just
> having NULL entries for the field in the main table is not going to be
> an overhead?
>
> Obviously indexing on something like group_id where there may only be 10
> or 20 values for all 100k records, would be a problem, but is there
> any way to get round that?
>
> Finally - will FB2 give any help in terms of performance when dealing
> with these sorts of question. In particular would there be any
> alternative way of handling this key structural element? ( Probably more
> appropriate on the Architecture list or developers? )
developers list :)
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.