我应该将字符串或int用于无效的数字值吗?
我正在尝试读取具有这些字段和值的CSV文件:
// "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"
参考
字段是唯一的,并且选择
字段可能为null。在此场景中,对于我的实体定义:
1。我应该使用字符串
选择
字段,因为它可能为null(空字符串) CSV文件?
2。我应该制作参考
字段pk,甚至是唯一的,我认为最好使用long
id字段并添加@column(unique = true)
参考
字段。那对吗?
3。对于startDate
字段,我认为我应该使用localdate
,而不是date
,因为它被弃用。是真的吗?
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?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您可以将CSV值解析为
string
,并使用integer.parseint ()
在写入数据库之前(以便在CSV值不可解析时编写有效数字或null
)。?覆盖现有值?)。您可以就此问题发表整个帖子。
? > java.time.localdate 是一个不错的选择。
有点pedantic,但是:
java.util.date()
已被弃用,但是date
本身没有弃用。不过,总的来说,java.time
软件包中有更好的选择(例如localdate
)。You could parse the csv value as
String
, and useInteger.parseInt()
before writing to the database (so that you write either a valid number, ornull
when the csv value isn't parseable).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.
Sure,
java.time.LocalDate
would be a good choice.A bit pedantic, but: various methods on
java.util.Date()
have been deprecated, butDate
itself is not deprecated. In general though, there are better choices available in thejava.time
package (likeLocalDate
).