Subject | RE: [IB-Architect] Re: One blob for many records. |
---|---|
Author | Jim Starkey |
Post date | 2001-03-29T17:54:02Z |
At 11:29 AM 3/29/01 -0500, you wrote:
header anytime garbage collection is performed on a record containing
the blob pointer, resulting in unnecessary writes, unnecessary
lock contention, nasty careful write problems, and eternal blobs
(or worse) in the face of a system crash. Garbage collection is
hard enough as is without the complication of tweaking reference
counts.
A secondary problem is how the system could ever recognize that
the same content was common to two records. If we put the burden
on the application programmer, he could just as well have a
proper separate table.
Jim Starkey
>Among the many problems of blob use counts is the need to update
>A similar approach is used by some news reader/server and email server
>software to minimize the message database size.
>
>All news messages have a unique ID (which combines incorporates the
>source domain and a GUID). So when messages are cross-posted to
>multiple newsgroups, the news server does need not store multiple copies
>of the message, it simply creates any entry in the newsgroup message
>reference lists.
>
header anytime garbage collection is performed on a record containing
the blob pointer, resulting in unnecessary writes, unnecessary
lock contention, nasty careful write problems, and eternal blobs
(or worse) in the face of a system crash. Garbage collection is
hard enough as is without the complication of tweaking reference
counts.
A secondary problem is how the system could ever recognize that
the same content was common to two records. If we put the burden
on the application programmer, he could just as well have a
proper separate table.
Jim Starkey