Ann,

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.

This can also been seen if you use MS Outlook, when you read a message
in one newsgroup list, if the message is cross-posted, when you go to
the other group the message is already 'marked' as read.

I also believe that Microsoft Exchange server uses a similar approach to
store messages for multiple recipients.


Sean

-----Original Message-----
From: Ann W. Harrison [mailto:aharrison@...]
Sent: Thursday, March 29, 2001 9:54 AM
To: interbase@...
Cc: IB-Architect@yahoogroups.com
Subject: [IB-Architect] Re: One blob for many records.

At 02:56 PM 3/29/2001 +0500, Dimitry Sibiryakov wrote:

> ... It's impossible to have two or more
>records referring to one blob, isn't it? Why? If I have an useful large
>picture, why have i to keep in the database two or more copies of it? I
>think it would be better to keep the counter of references to blob and
>remove it only when the counter reaches zero.

I'm replying both to this list and to the IB-Architect list at
yahoogroups.com,
because your idea is interesting and deserves some discussion. My
inclination
is to suggest that you create a table of blobs and link to that table,
keeping
a reference count with triggers. In short, I would push the problem up
from
the engine to the application. My reason is that different applications
would
expect different behavior from update and delete. In many cases, but
not all,
an update would create a new blob, linked only to the updater. In many
cases,
a delete should decrement the reference count and not remove the blob
unless the
count goes to zero. On the other hand, a shared document should reflect

changes
to all tables linked to it.

Does any one have experience with systems that behave like this?
Comments?


Regards,

Ann
www.ibphoenix.com
We have answers.


To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com



Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/