Subject | Re: [IB-Architect] External file handling |
---|---|
Author | Jim Starkey |
Post date | 2000-06-16T14:10:20Z |
At 06:29 PM 6/15/00 -0700, Jason Wharton wrote:
control, transaction backout, database consistency, garbage collection.,
and access control. They are backed up and restored with the rest of the
database. Blobs were invented to solve the problems induced by storing file
names database tables. External blobs, especially with the intent to
backup and restore them independently of the database, is a huge step
backwards.
The backup problem, howerver, is real. The disaster recovery
strategy of InterBase is, well, a disaster. On the bright side,
most database disaster recovery strategies are based on the
concept of magnetic tape, a quaint medium more suited for display
next to punched cards than modern computer systems.
Like most hard problems, the place to start is to collect and
prioritize requirements. When we have a handle on the problem,
we can work on a solution.
So to answer you question, what would it take ... my death or permanent
incapacitation.
Jim Starkey
>Blobs are stored in the database because they are subject to concurrency
>What would it take to get IB capable of storing BLOB contents in individual
>external files? Just allow it to determine a random file naming convention
>and keep a path name in the metadata for the table or column (domain) to
>tell where all the BLOB files are located. Then, InterBase would maintain
>the files external to the GDB allowing a daily backup to only send to tape
>the new guys for the day.
>
control, transaction backout, database consistency, garbage collection.,
and access control. They are backed up and restored with the rest of the
database. Blobs were invented to solve the problems induced by storing file
names database tables. External blobs, especially with the intent to
backup and restore them independently of the database, is a huge step
backwards.
The backup problem, howerver, is real. The disaster recovery
strategy of InterBase is, well, a disaster. On the bright side,
most database disaster recovery strategies are based on the
concept of magnetic tape, a quaint medium more suited for display
next to punched cards than modern computer systems.
Like most hard problems, the place to start is to collect and
prioritize requirements. When we have a handle on the problem,
we can work on a solution.
So to answer you question, what would it take ... my death or permanent
incapacitation.
Jim Starkey