Bodgitt & Scarper - Database Record Numbering

[Harry Henriques]

Hi,

I passed the SCJP on November 13th, and this is my first post to the SCJD forum. I've downloaded the Bodgitt & Scarper assignment from SUN. I have a good bit of the Data class written, but I have a simple sounding question for my fellow bloggers.

The records in my flatfile database don't have record numbers. The DBAccess interface (in the project specification) specifies that "long" recNo's should be used to reference database records. There doesn't seems to be any advantage in using the "long" precision of the record number variable by generating random numbers as the records are read. Rather, I just read the records sequentially starting with record number 1 through record number 30 (let's say), and read all the records until I encounter end-of-file. I will never need all the available bits in "long recNo" to encode all of the record numbers in my flatfile database. This makes sense, right? There isn't any reason to generate 64-bit numbers for database record numbers?

I know this question is pretty simple, but my questions are sure to get more difficult.

Thanks,
Harry

[Roberto Perillo]

Howdy, Harry!

There doesn't seems to be any advantage in using the "long" precision of the record number variable by generating random numbers as the records are read.

Generating random numbers? Champion, the thing is simpler: the records don't have a "record number" field, so the record number is the position that each record appears in the .db file.

[Andriy Pererva]

Roberto,
I have the same issue with my B&S assignment about record numbering strategy.

so the record number is the position that each record appears in the .db file.

What the position means?
a) the real byte position of the data block in the db file that used as argument in RAF.seek() method
b) simply ordinal position of the record in file (i.e. 1, 2, 3... etc)

In case of b) how should I treat deleted records? Simply skip them and don't include in numeration order or keep their numbers and throw RNFE when the number of deleted record is requested?

[Roel De Nijs]

Hi Andriy,

I would opt for b. But you can't skip them in numeration, because that will lead to big problems. Because you'll use a formula to calculate the starting position of a certain record. something like:

positionRecordSection + (recNo - 1) * recordLength

If you have 3 records and the 2nd one is deleted, then the recNo will be:

record1 has recNo 1 (or 0)

record2 has no recNo (deleted)

record3 has recNo 2 (or 1)

So instead of reading record3, you will read the deleted record2. And record3 will be read instead of record4,...

Kind regards,
Roel

[Vlad Djordan]

Hi,

I would have to agree with Roel,

But you can't skip them in numeration

A deleted record in the database file provide by Sun is not the same as a deleted
record in an actual RDBMS.

What this means is, if you were to execute the delete method on your database file,
you shouldn't completely remove the record information and the record number. Either
the space which the previous record used to occupy will be available for reuse and will
be reused when creating a new record, or you can opt out not to reuse the record space.

Either way, you have to write that deleted (or possibly a new record in its place) record
back to the file.

Vlad

[Harry Henriques]

Vlad Djordan wrote:
Either way, you have to write that deleted (or possibly a new record in its place) record
back to the file.

Hi Vlad,

I'm somewhere in the middle of designing and implementing a Bodgitt & Scarper SCJD assignment. The first part I worked on was implementing the Interface provided by Sun with methods that are used to modify the flat-file database. The second part I worked on was implementing the GUI. I now have the GUI talking to the database through the business layer. Since my assignment only says that I must be able to search records, update records and book contractors, I'm not concerned with deleting records, or creating records.

There aren't any record numbers in my flat-file database. Record numbering relies totally on the serial position of a record within the flat-file database. Therefore, you can't physically "delete" a record from the flat-file database, because you would change the record number of every record after the deleted record.

Regardless, I mark deleted records by writing a byte to the initial field in the records, invalidating them. It is not possible for me to read a record that has been deleted in this manner (by design). I don't have to deal with deleted records in my presentation layer. Reading a deleted record throws a RecordNotFoundException.

Best regards,
Harry

[Roel De Nijs]

Hi Harry,

I'm not concerned with deleting records, or creating records.

I guess you implemented the delete and create methods from the given interface? These methods aren't referenced from the assignment, that is correct. But you have tested your delete/create methods in some way to see if you have implemented it correctly.

And I guess you have misunderstood Vlad a bit, because he is saying exactly the same thing as you You can't simply physically delete a record from file (because it will mess up the record numbers of the other records), you just set a flag to "deleted" or "valid".

Kind regards,
Roel

[Harry Henriques]

Yes Roel and Vlad,

I have implemented and tested the createRecord() and deleteRecord() methods in my SCJD assignment, because I was required to implement them. They are unused and inaccessible from the presentation layer because their use isn't required by the specification.

Best regards,
Harry

[Vlad Djordan]

Hi,

And I guess you have misunderstood Vlad a bit, because he is saying exactly the same thing as you

I certainly am. Harry I believe your approach is correct. My response was originally just an addendum to the
answer provided to Andriy, that you can't ignore records marked with the deleted flag and why you can't ignore them,
and that every record marked as deleted has to find its way back to the file one way or the other.

Vlad

[Mark Blackwood]

Sorry, I think my question's been answered above... Deleted!

[Roberto Perillo]

Mark Blackwood wrote:

Sorry, I think my question's been answered above... Deleted!

Ok... so welcome to JavaRanch, anyway!