Datetime column vs Date + Time columns I am designing a table for a system that saves a number of logs. We are looking at ~200 entries per second.

We are using SQL-Server 2012 Enterprise Edition.

I have a question regarding breaking up a Datetime column into two columns, Date and Time.

My thinking behind the question. I would say once the data is stored in the database, most searches are going to be based on a daily basis, give me all results from today / 10th of Jan.

Now I do still need to store the time as well. So if I store it as a datetime, when executing this query sql will have to load the whole datetime fields and then only look at half of the data.

So by possibly storing date in its own field it can look at only what it needs. 

But then on the other hand if you do specify a time in your query, it now has to check the value of two columns.

So I would like the input from you SQL Gurus on which option would have better performance for queries on a large database. 

For all I know datetime could be highly optimised and a much better solution than breaking it up.
I would use DATETIME2 as opposed to DATETIME for any new development work at this point. If you don't need sub-second granularity, use DATETIME2(0) and you'll see some space savings as well.

From here I would start experimenting. If performance is poor just querying off the single column, I'd then try adding persisted computed columns to separate out the date and time components. This will ensure that the separated DATE and TIME columns will always be the same as the "master" DATETIME2(n) column.