Salem B#6
Conversation
composix
left a comment
composix
left a comment
There was a problem hiding this comment.
Overall, this is a solid implementation that shows a good understanding of JDBC, prepared statements, and joining related tables. The code is clearly structured by separating the insert and fetch logic, and the use of prepared statements makes the database interactions safer and easier to read. The fetch query also demonstrates a good understanding of how the different tables in the library schema relate to each other.
| @@ -1 +1,92 @@ | |||
| -- Write here your DDL statements to create the tables for the database. No newline at end of file | |||
There was a problem hiding this comment.
Overall, this is a well-structured schema with clear primary keys, foreign keys, and many-to-many relationship tables.
| card_id SERIAL PRIMARY KEY, | ||
| card_number TEXT UNIQUE NOT NULL, | ||
| card_issued_on DATE NOT NULL, | ||
| card_expires_on DATE NOT NULL |
There was a problem hiding this comment.
Here is a good opportunity to add a contraint on the issued en expiry dates: CHECK (card_expires_on > card_issued_on). Also consider placing date/timestamp contraints on the borrows table below.
| member_name TEXT NOT NULL, | ||
| member_phone TEXT NOT NULL, | ||
| member_address TEXT NOT NULL, | ||
| FOREIGN KEY (card_id) REFERENCES cards (card_id) ON DELETE CASCADE |
There was a problem hiding this comment.
Is this cascading delete really what you intended? Now if you delete a card then the member will also be deleted. Also as card_id can be NULL it looks like ON DELETE SET NULL would be the intended choice.
| CREATE TABLE authors | ||
| ( | ||
| author_id SERIAL PRIMARY KEY, | ||
| author_name TEXT UNIQUE NOT NULL |
There was a problem hiding this comment.
Although it is indeed rare, it could be possible that two different authors happen to have the same name. Relaxing the UNIQUE contraint allows for indicating that there are multiple different authors with the same name.
| CREATE TABLE tags | ||
| ( | ||
| tag_id SERIAL PRIMARY KEY, | ||
| tag_name TEXT UNIQUE NOT NULL |
There was a problem hiding this comment.
Tags are usually short so VARCHAR would be a better choice than arbitrary TEXT.
| member_email TEXT UNIQUE NOT NULL, | ||
| member_name TEXT NOT NULL, | ||
| member_phone TEXT NOT NULL, | ||
| member_address TEXT NOT NULL, |
There was a problem hiding this comment.
It could be nice to further normalize addresses in a separate table. This allows working with e.g. postal codes to uniquely identify addresses. This would make address verification easier.
There was a problem hiding this comment.
Compiled .class files do not belong in Git, but sometimes get accidentally commited. To make this easier a .gitignore file with the line: target/ would prevent build output to be accidentally committed.
|
|
||
| System.out.println("- Borrows -"); | ||
|
|
||
| while (rs.next()) { |
There was a problem hiding this comment.
The fetchData query is very nice and returns a relevant non-technical view without primary keys. The program could present richer output based on the query. For example, like so:
String row = rs.getString("member_name") + " -> " +
rs.getString("book_title") + " (" +
rs.getString("copy_barcode") + "), borrowed at " +
rs.getTimestamp("borrowed_at") + ", returned at " +
rs.getTimestamp("returned_at");
2 participants
No description provided.