On Wednesday 03 October 2007 01:15:49 Andrew Jensen wrote: > Hi Drew,
> One final point - HSQLdb also imposes a limit of 2 Gig on any single > table - so if one actually moved a 2 Gig image for instance into a > field - that would be it for the table. One field only, with one > record - in fact with overhead you would be some number of bytes short > of the 2 Gig limit..but hey who wants to that picky about this. > > HSQLdb also places an 8 Gig limit on the overall database. > > Now that said - Base with an embedded database can get no where near > those limits. In Base the entire database must exist in Memory - ok > with virtual memory that would be possible, but it would be unusable > performance wise as the OS would be thrashing like crazy with the swap > table. Unless you have a machine with 4 or 8 Gig of real memory. > > Then there is one other issue. The internal buffer for result sets. > This buffer has a fixed size - in the embedded Base model I believe > that is 50 Meg. That buffer is utilized as a shared resource for all > open result sets. The size of each row becomes very important then for > the performance characteristics of the database, as the row size > increases the number of records ( rows ) that can be buffered > decreases causing more memory allocation to take place as one moves > through a result set. If you are designing a database with numerics > and relatively small char fields this is not a big problem, but as you > start to store large binary fields ( images, sound files, documents ) > this has to be accounted for. > > This is one of those common mistakes I was talking about. If you are > gong to be dealing with these large type objects it is important to > not include them in a table that may need to be scanned, as to do so > would require moving all of that information into the buffer for each > and every record. Instead it is better to create two tables, one with > the data that you might search against ( Names, Dates, Codes ) and the > create a second table that contains a key field, which is also a > foreign key to the master tables PK and the large object. Not doing so > will create a real problem with performance overall. > > Anyway that is all I have for the moment. I hope that helps. I'll do > my best to get to that page on the wiki for the data type grid asap. > Well I learnt something useful in all of the above, especially the bit about the ResultSet buffer size :-) Thanks !! Is this stuff also on the Wiki ? If it is, I think I'll translate it into French for the French n-l group. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
