Should I use String or int for nullable numeric values?-CodePudding

I am trying to read a csv file having these fields and values:

// "reference"         "choice",    "startDate"
// "123",              "3",         "06.03.1987"
// "Set 1",            "1",         "11.06.1999"
// "Set 2",            "2",         "05.07.2002"
// "Set 3",            "",          "05.07.2002"

The reference field is unique and the choice field may be null. In this scene, for my Entity definition:

1. Should I use String for the choice field as it may be null (empty string) in the csv file?

2. Should I make the reference field PK or even if it is unique, I think it is better to use a Long id field and add @Column(unique = true) for the reference field. Is that right?

3. For the startDate field, I think I should use LocalDate, instead of Date as it is deprecated. Is that true?

CodePudding user response：

1. Should I use String for the choice field as it may be null (empty string) in the csv file?

You could parse the csv value as String, and use Integer.parseInt() before writing to the database (so that you write either a valid number, or null when the csv value isn't parseable).

2. Should I make the reference field PK or even if it is unique, I think it is better to use a Long id field and add @Column(unique = true) for the reference field. Is that right?

There are a number of considerations for how to choose a primary key, whether uniqueness makes sense, how to handle duplicates for the unique value (fail the new addition? add a related row? update existing row, overwriting existing values?). You could make an entire post about this question.

3. For the startDate field, I think I should use LocalDate, instead of Date as it is deprecated. Is that true?

Sure, java.time.LocalDate would be a good choice.

A bit pedantic, but: various methods on java.util.Date() have been deprecated, but Date itself is not deprecated. In general though, there are better choices available in the java.time package (like LocalDate).