I'm trying to understand our software vendor's decision to keep date and time in separate columns. For example, when the row was created or updated. Both time and date are DateTime columns. We are using SQL Server 2005.
The database holds our ERP system's data and I believe the largest tables contain about ~3 million rows. Most of the tables are roughly between 100 000 – 1 000 000 rows.
I would personally by default choose a single DateTime for a single timestamp. This would allow easier time difference calculations and the date and time parts could be easily extracted from the timestamp. It would also consume less space.
Is separating date and time bad practice or is there something very brilliant in this design I don't understand?
Best Answer
My guess is that it's a legacy support thing (i.e back in version 1 of their software, they had date and time in seperate fields and they've been forced to support it because it always worked that way).
That said, there's nothing brilliant about seperating date and time, so there's nothing you're missing.
(The other option is that your ERP system developers didn't know that a datetime field can store a date and a time, but far more likely is that they had a business requirement to make it work the same as prior versions.)