Check-in function, data storage time, year, month, day, why use varchar
do a check-in function
`create_time` decimal(20,3) NOT NULL,
`create_date_ymd` varchar(15) NOT NULL COMMENT "",
`create_date_ym` varchar(15) NOT NULL,
`create_date_y` int(4) NOT NULL,
`create_date_m` int(2) NOT NULL,
`create_date_d` int(2) NOT NULL,
I don"t quite understand why the create_date_ymd field is varchar instead of int
. The latter fields are used to clean up useless data
.
Doesn't the
field name create_date_ymd ymd refer to the time format? If the formatted time is int, then transfer it again? In fact, I think it's better to save the date type
if there is no symbol in the middle, you can also use int
to store the Date type, but the conversion between the foreground and background of the varchar type is convenient.
this depends on the habit of the person who created the datasheet. If you look at this table, you can see that you like to use varchat rather than the date type
if the front-end display is equivalent to the back-end, there is no problem with using varchar.
but for now, it is common practice to use datetime or timestamp to save date data.
in this way, no matter whether the front end shows Y/M/D
, Y-M-D
or Y M month D day
, the back end can be easily converted (because the saved data is not bound to format).
but if you do this, the create_time above doesn't make much sense, because the precision of date and timestamp can be reduced to seconds, or you can calculate the date and time back.
so, I think, the fields after create_time may have been added later by some requirement?
habit problem. Personally, I think int or date is better
this is a personal habit problem. I usually save bigint to microseconds
habit problem. I am int or datetime
, so I asked the watch designer. When querying the data for a certain day, you can directly use create_date_ymd = '2018-03-279.
as long as it works ~