aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes which one is the primary key? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "which one is the primary key?" Watch "which one is the primary key?" New topic
Author

which one is the primary key?

Mingwei Jiang
Ranch Hand

Joined: Feb 19, 2004
Posts: 63
I have the Database schema like this:

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
Ranch Hand

Joined: Jun 23, 2004
Posts: 172
There might not be a good primary key in this situation. I would not worry about it too much.


SCJP 1.4 (91%)<br />SCJD 1.4 (376/400, 94%)
Hanna Habashy
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
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)


SCJD 1.4<br />SCJP 1.4<br />-----------------------------------<br />"With regard to excellence, it is not enough to know, but we must try to have and use it.<br />" Aristotle
Mingwei Jiang
Ranch Hand

Joined: Feb 19, 2004
Posts: 63
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 and it has the type , for instance,. How can I deal with this? To build some transformation mechanism?
Hanna Habashy
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
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
Ranch Hand

Joined: Feb 19, 2004
Posts: 63
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
Ranch Hand

Joined: Jun 23, 2004
Posts: 172
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
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
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
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
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 ]

Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Mingwei Jiang
Ranch Hand

Joined: Feb 19, 2004
Posts: 63
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".
Julian Kennedy
Ranch Hand

Joined: Aug 02, 2004
Posts: 823
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
Ranch Hand

Joined: Feb 19, 2004
Posts: 63
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
Ranch Hand

Joined: Jun 23, 2004
Posts: 172
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?


Just something to think about.
Eugenio Nassu
Greenhorn

Joined: Aug 09, 2004
Posts: 16
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...


SCJP 1.4
Richard Jackson
Ranch Hand

Joined: Jun 25, 2003
Posts: 128
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):


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


Regards, Richard
Hanna Habashy
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
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.
 
 
subject: which one is the primary key?