On 3/3/2016 2:30 PM, les...@lsces.co.uk wrote:
Initially when I ran websites, the normal practice was to save
everything in the database, pictures, pdf's, documents, and so on. The
databases soon got too large and while just having one file to back up
was nice, NOT using blobs for that content was a lot easier. Rsync to
backup machine, including a nightly backup of the 'real' data. The
cross over point is perhaps when you need to do a text search, but
even that is easier if a pdf or doc is preprocessed to provide a copy
as simple text. Which nowadays is what ends up in my blobs. Replace
vast blob zone with the native file system?
Where i can see a useful segregation is archival data which will never
be modified. Would be very usefull if all that could be backed up on a
Slow cycle, and only the real dynamic data kept in the primary table
space? But one can do most of that by having multiple databases anyway?
You know, that's a really good idea. Disk is almost free, too cheap to
meter (so to speak). Store something once and just don't worry if it
goes out of style...
Sent from my android device so quoting is crap ... need to kill these
painful email clients!
-----Original Message-----
From: Ann Harrison <a...@qbeast.net>
To: For discussion among Firebird Developers
<firebird-devel@lists.sourceforge.net>
Sent: Thu, 03 Mar 2016 18:37
Subject: Re: [Firebird-devel] RFC: Tablespaces
On Thu, Mar 3, 2016 at 1:02 PM, Jim Starkey <j...@jimstarkey.net
<mailto:j...@jimstarkey.net>> wrote:
>> Non-goals:
>>
...
>> 2. Store blobs in other than the table's data space.
> Why not allow blobs to be separated from regular data ?
OK, reasonable question. Obviously they could, but it would require
either storing small blobs off page or changing the mechanism used for
blob ids, or both. It also runs the risk of the records and blobs
diverging, which is very, very bad.
I think the benefit of separating records and blobs is quite limited.
Large blobs have at least their rear end stored on blob pages that
aren't scanned for exhaustive retrievals. Moving them to a separate
data space within the same table space so they don't share the record
number space with records is well worth considering.
I think the problem is with the size of backups and the amount of time
taken by a backup/restore for a database with a significant number of
large blobs.
Cheers,
Ann
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
