which one is the primary key?

[Mingwei Jiang]

I have the Database schema like this:

 
Field descriptive name, Database field name, Field length, Detailed description
Subcontractor Name,     name,                32,           The name of the subcontractor this 
                                                           record relates to.
City,                   location,            64,           The locality in which this contractor
                                                           works
Types of work performed, specialties,        64,           Comma separated list of types of work 
                                                           this contractor can perform.
Number of staff in organization, size,        6,          The number of workers available when 
                                                          this record is booked
Hourly charge,          rate,                 8,          Charge per hour for the subcontractor.
                                                          This field includes the currency
                                                          symbol
Customer holding this record, owner,          8,          The id value (an 8 digit number) of the 
                                                          customer who has booked this. Note that 
                                                          for this application, you should 
                                                          assume that customers and CSRs know
                                                          their customer ids. The system you are
                                                          writing does not interact with these 
                                                          numbers, rather it simply records them. 
                                                          If this field is all blanks, the record
                                                          is available for sale. 
 

I don't know which field is the primary key(recNo). I suppose it is the Subcontractor Name, but if this field is the primary key, is it said that a Subcontractor can only reserved by one customer at a time? Is it to say that a whole company can only serve one customer if booked by this system?

[Andrew: Modified maximum line lengths to try and get code block to fit on single page]
[ July 26, 2004: Message edited by: Andrew Monkhouse ]

[Robert Konigsberg]

There might not be a good primary key in this situation. I would not worry about it too much.

[Hanna Habashy]

hi Mingwei:
In my project, by looking at all records in the given database, I identified that the primary key were contractor name and location together. It makes sense to me. There could be many contractors with the same name, i.e. one company has many offices. However, you cannot register two contractors with the same name and the same location, as it is very low probability to find two contractors with the same company name, and located in the same town.
I think it is important to decide on a primary key, becasue when you update or add a new record, there is a DuplicateKeyException (this req. is in B & S)

[Mingwei Jiang]

Originally posted by Hanna Habashy:
hi Mingwei:
In my project, by looking at all records in the given database, I identified that the primary key were contractor name and location together.

hi Hanna:
Thank you for your reply, but in my DB interface provided by SUN, it has many methods related to

 recNo 

and it has the type

 int 

, for instance,

 public String[] read(int recNo) throws RecordNotFoundException; 

. How can I deal with this? To build some transformation mechanism?

[Hanna Habashy]

hi Mingwei:
My project specifications had similar requirements. I considered the record location in the database is the record number. For example: The first record after the metadata is records number 1, the seconde is number 2, etc.
However, this is how I did it, I believe there are other people did it in different ways.

[Mingwei Jiang]

I think I get you. Thank you for your reply.
I figured out another approach today in my company. Hope you can correct it. I think in this project, performance is not the most important. So I think I can use hashcode to compute the recNo, and for the same String, it has the same hashcode. So if I want to find a record by recNo, first I compute the hashcode of the "primary String" on JTable, then find if some record in the database file has the same hashcode. the worst, it need to compare every record in the database file. There're many approaches, but I think yours is better.

[Robert Konigsberg]

Mingwei,

I think you may be overengineering. It's best to keep it simple. As Hanna says, think of the first piece of data as Record Number 1 (or heck, Record Number 0.)

Hash code for record number can introduce many problems, like, for instance, clashes. What happens if two records evaluate to the same hash value?

Also, remember before when I said not to worry about primary keys? While the interface itself documents that it can THROW duplicate keys, it doesn't mean that you NEED TO. So with that said, do you need to? An appropriate key would be a "Contractor/Reservation ID" Keys are values that, traditionally, won't change. What happens if a contractor is bought out and gets a new name? Your hash value will change!

Here's what I put in my "choices.txt" file:

Another exception issue in DB was DuplicateKeyException. I wrote
a class called DuplicateKeyException, but I never throw it. After
all, nothing anywhere defined a primary key, so I let it alone. I
documented that it is neither thrown nor used.

[Hanna Habashy]

Mingwei ,
I agree with Robert. What is the point of hashing a number to get another number..??
Robert mension that his instructions didn't mandate him to throw the exception. My instruction did. update() and book() or creat() methods specifically throw DuplicateKeyException, so I had to deal with it.
Read your instruction carefully to find out wether it is a must or and option.

[Anton Golovin]

In my project record number one starts at 57th byte, and a record is 159 bytes. so when you read the file at the server startup, you can ascertain these numbers as to your project, and then use RandomAccessFile to read off a specified location for n number of bytes, the bytes in your database's record.

You don't need a primary key for this assignment. Just keep things as simple as they need to be to pass - it's the certificate you care about.
[ July 28, 2004: Message edited by: Anton Golovin ]

[Mingwei Jiang]

Hi everyone:
Thank you for all your replies.
In my previous reply, I mean Hanna's recNo implementation is better, I think I will use it.
I know SUN's requirement is to keep the project as simple as possible, but we shouldn't drill on it. I don't think define a primary key or consider another recNo implementation is a complicated thing. I think primary key sometimes is a standard part of a table, especially on a single table. If a single table doesn't contain a primary key, we'd better consider redesign it, though it is impossible on SUN's project. I agree on Hanna's idea that Subcontractor Name and City altogether is a primary key. Subcontractor Name and owner together shouldn't be the primary key, because owner may has null value.
For the recNo implementation, Hanna's is better, but mine is not complicated, its disadvantage is just the performance. Since they don't use a RDBMS, I think their records are not too much, if so, I think they should consider to buy a RDBMS, whatever how good you build your program, the underlying database mechanism decide the basic performance index, do you agree with me?
Furthermore, hashcode is defined in Object class. Therefore, every object has a default hash code implementation. That hash code is derived from the object's memory address. But the String class override it. The String class has a hashCode method that computes a hash code derived from the characters in the string. So I said "the same String has the same hashcode" and may be I need to add one word that a different String must have a different hashcode, if you don't believe, you can test it. And also you can override equals method to make objects equal if they have the same hashcode. It is not just what I say, you can find it well documented in "Core Java2 Volumn II-Advanced Features 5th Edition".

[JulianInactive KennedyInactive]

Hi Mingwei,

I think Hanna's approach coupled with Anton's suggestion is the way to go, as you appear to concede.

Robert's point about not having to throw a DuplicateKeyException, in spite of it being included in the throws clause of the create() method, is a valid one. A method that claims to throw an exception doesn't have to contain any code that actually does throw the exception, although it's probably not great practice to implement it in that way.

Be careful with your assumptions about the hashCode contract. Two objects that are equal must have the same hashCode, but the converse is not guaranteed to be true; i.e. two objects that have the same hashCode are not necessarily equal.

Also, there are many factors that can affect the performance of an application (even one as simple as B&S). Whilst the DB access strategy is a key performance consideration, it is only one of many. You can have lightning fast database access and still write a dog of an application if you make a mess of other factors.

Hope this is useful,

Jules

[Mingwei Jiang]

Hi Julian,
Thank you for your reply.

But I think you still misunderstood me, I think we can override equals method to make the two objects have the same hashcode be equal.

[Robert Konigsberg]

BE VERY CAREFUL!!!

Are you saying:
1. Strings that are the same will have the same hashcode.
2. Strings that are not the same WILL have different hashcodes.

Because that is a WRONG AND DANGEROUS ASSUMPTION.

The correct statement is:
2. Strings that are not the same MAY have different hashcodes.

Here's a concrete example: hashCode returns an int. So, will all these strings return a distinct hash code?

for (int i = Integer.MIN_VALUE; i < Integer.MAX_VALUE; i++)
{
    Integer iv = new Integer(i);
    int hashCode = iv.toString().hashCode()
}
int otherHashCode = new Long(Integer.MAX_VALUE + 1).toString().hashCode();

Just something to think about.

[Eugenio Nassu]

I'm taking the same approach as Hanna. The record number is the position in file. So the recordNotFoundException makes sense. But I didi not realize if DuplicateKeyException will be thrown any time...

[Richard Jackson]

Hi,Hanna and Robert

As you two's words,we must notice what instruction.html said carefully.

Just like recNo,in my assignment,is also as argument of several methods (like readRecord(),update(),etc).

Now that the recNo is record number representing the location of some record, attempt to write pseudocode to describe reading records as follows (raf is a RandomAccessFile instance):

// skip fixed bytes and go to the start point of records
raf.skipBytes(HEADER_LENGTH+SCHEMA_LENGTH);
// ready for reading records
if(record flag is valid){  
   // make a loop to iterate all records 
   for(int recNo=1;recNo<;recNo++){
       raf.skipBytes((recNo-1)*recordSize);
       // read current record
       ...
}else if(record flag is deleted or record not exist){
   throw RecordNotFoundException();
}
  

Is that above true? Please comment on and implement real code.
I feel confused about reading records. So wish your comment to help me.

Best regards, Richard

[Hanna Habashy]

Richard,
here is a simple instructions for reading a single record

1) header length = calculate the schema length, and the the metadata length
2) record length = caluculate record length + the delete flag size
3) record Position = record length * record number
4) offset = record position + header length
5) position the curser at the offset number.
6) if success, then the records exist (throw exception)
7) else, the record doesn't exist
8) read the delete flag to determine if the record is valid or not
9) if not valid, throw exception
10) else, return that record

YOu need to keep track of the numbers, that is the tricky part.
if you are reading all records, it is easier.
Just position the curser at the first delete flag (after the headers), if it is deleted, then skip that record. If it is not deleted, then read the record, and then keep going until you reach the end of the file.