Splitting time and date in two separate date columns, in SQL server, is best practice?

Is it best practice to split a dateTime in two datetime SQL columns?

For example, 2010-12-17 01:55:00.000 is put in two colums,

• one column containi开发者_开发百科ng a datetime for the date portion: 2010-12-17 00:00:00.000
• one column containing a datetime for the time portion: 1900-01-01 01:55:00.000

I'm being told this is best practice because at some point SQL 2000 didn't allow to put time in a date? and that there are even data storage standards that enforce this and that some companies have ensure that all their data is stored in that manner to comply to some data storage standards?

If this is the case, I'm sure someone heard about it here, any of this sounds familiar?

---

In sql server 2008 you have date and time data types so this becomes a non issue. datetime always allowed for time even back in sql server 6 and 7

the reason people split it up is because with everything in 1 column a query that returns all orders placed between 3 and 4 PM for any day requires a scan, with a time column this can be accomplished with a seek (much, much faster)

---

Starting in SQL 2005 I would do only one column.

If you wanted this information to be Sargable I would use computed columns instead. This way you can query on date or time or both and your application code is only responsible for maintaining the one column.

---

I know this is old, but another reason you might want to keep separate is for user input (and GenEric said in a comment that this is for time management). If you allow users to enter date/time as separate fields, and you want to be able to save the data with either field being empty, it is nice to have 2 separate null-able fields in your database. Otherwise I guess you either have to resort to kludges where certain date values equal "empty" or add extra bit fields as "no time / no date" flags.