Thanks for the response.. Here's my situation: The app is generating records with sequential numeric keys and over time the records are deleted with the file returning to a count of zero.. The record sizes can vary considerably from record to record...
Currently we are using dynamic files and are constantly having to resize and generally having to "maintain" the files, and it is becoming quite a headache for us .. Right now, we are just looking for other options and I had seen sequentially hashed files in the manual, and it said that they are bested suited for cases with sequential keys (but says nothing about create not delete etc) - so I thought I would ask... Looks like we may just have to spend time working on some admin scripts to maintain the dynamic files "automatically"... Ray -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Anthony W. Youngman Sent: 20 October 2009 16:46 To: [email protected] Subject: Re: [U2] Sequentially Hashed Files In message <5e5ef002669716488cf5f69288ba6b093bf...@msgl-lon01-es01.msgluk.local>, Raymond P. de Bourbon <[email protected]> writes >Does anyone have any experience using Sequentially hashed files? The >documentation on Sequentially hashed files is not very explicit about >what kinds of benefits or problems can be expected / experienced.. It >also only hints towards one use case, but IMO doesn't do enough to >clearly define when these types of files are actually beneficial and >why... > I've never had any need to use sequentially hashed files, but I'm quite happy to try and explain it ... Two questions to start with: Firstly, is your app generating sequential numeric keys? And do you only create records, never delete them? Secondly (less importantly), are your records of a roughly consistent size? The point of sequential files is that, if your answer to both questions is yes, a sequential file is trivially and perfectly balanced. And such files are common enough to make creating a special file type worth doing. Rather than trying to find some hash algorithm that does a good job, sequential files use the key value as the hash value. So if each record fills a group, record 1 goes in group 1, record 2 goes in group 2, etc etc. If two records fill a group, then it goes 1, 1:2, 1:3,2, 1:3,2:4, etc etc. I would have thought that if the typical record ended up in overflow, then sequential would be a good match for sequential keys too regardless of whether the size is consistent. However, DON'T take my GUESS on that. And bear in mind the advice is, if the answer to the first question is "no", then DON'T go near sequential files. They're a special case, for a special-case situation. It's just that that "special case" is actually quite common. Cheers, Wol -- Anthony W. Youngman <[email protected]> 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - <http://www.maverick-dbms.org> Open Source Pick _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
