Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Associated Disk Space

 
Jeff Haynes
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the URLyBird assignment the DBAccess interface has a method deleteRecord in which the comments describe it as deleting the record, and making the record number and associated disk storage available for reuse.

Which seems to imply that deleted records are never written back to the database file?

However the database file is defined to specify a deleted flag.

Thinking over this, what it seems to imply is that when a record is deleted, this doesn't actually remove the record from whatever structure you have loaded your records into but sets a delete flag. Then when a new record is added to the database, it is placed into the first deleted records space that is returned from your structure.

Is this how these directions are understood by most?


Thanks!
 
Daniel Dalton
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jeff

Thinking over this, what it seems to imply is that when a record is deleted, this doesn't actually remove the record from whatever structure you have loaded your records into but sets a delete flag. Then when a new record is added to the database, it is placed into the first deleted records space that is returned from your structure.


Yes that's more or less my understanding of it, at least as far as the resulting disk-file structure. I'm sure there are loads of possibilities for how one might handle this in terms of data structures in memory - I personally wouldn't assume that the data from all the records had to be held in memory in a data structure. Also, there may not be any deleted records, in which case a new record needs to be appended to the end of the file.

It's similar to an old dbase dbf format in which records were marked as deleted but the disk space not reclaimed until a pack operation was performed.
 
Chirag Patel
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jeff,
I posted a similar question somewhere else. I may as well copy and paste it over here since this topic is more relevant. In my opinion the delete flag is not needed. This is how my database works.

First I read in the records into a Hashtable. If the record in the initial database file is marked as deleted it is ignored and not added. The keys to the Hashtable are the records numbers which are assigned in numerical order starting from zero, as each record is read. I have a getFreeIndex() method which searches the Hashtable for the smallest integer which has not yet been used as a key. I do not use the position of the record in the file to determine its record number.

If a record is deleted the object is removed from the Hashtable, and that particular index becomes free. The record numbers for others records remain the same. The whole Hashtable is re-written to file whenever a change is made to the database (updates/deletions). This way, only valid records which have not been deleted are written to file. If records have been deleted the file size becomes smaller. Therefore the delete flag is not really needed, although I do take it into account (by ignoring it) in the initial reading in of the file, just in case the supplied database file happens to contain records marked as deleted.

When i first read my instructions the two requirements of disk storage becoming available for reuse and the use of a delete flag seemed to conflict. However now im thinking what they might have meant was that the disk storage should become available for re-use by at least the db application. I dunno.

What do other people think?

Chirag
 
Daniel Dalton
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Chirag - just my opinion, but unless I've misunderstood, re-writing the whole database each time might not scale very well, and might severely impact concurrency for multiple threads... I couldn't say it was a "wrong" thing to do, but can you justify the choice to do it that way as you'll have to do in choices.txt?
 
Chirag Patel
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Daniel, i think the database wouldnt need to scale well. I cant forsee the database ever needing to be over a few 100k at the most. My assignment is the B&S one where only information about contractors is stored. At present its only 5k. At those sizes the cost of writing to disk is negligible. I think given the nature of the assignment performance isnt really an issue here, most of the operations would be reads, which would be faster if the records are already in memory in a datastructure. The amount of data we are dealing with is so small that both methods , reading to a datastructure, or not, is equally valid in terms of performance.
 
Daniel Dalton
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Chirag - again, no problem as long as you can justify your choices! The whole point of the exercise is to make you think, to consider consequences and to weigh options. You're right - performance is not an objective of the test per se.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic