This kind of thing is difficult to answer definitively. Every situation is different. Even in your application what may be good today may not be tomorrow by a change of hardware, database version, usage pattern, etc. Just measuring to be sure. So like any measurement I make it won’t serve you or waste time.
You probably want to know what intuitively performs best. So I’ll say that’s the way you’re doing it. Comparing a character tends to be faster than comparing a date that besides being a larger data will probably need checks (if it is null
, for example) and extra conversions. But I lost count of how many times what was intuitive turned out wrong. So I can only reinforce to take the test with both.
I would suggest testing if anything changes to use the column exc
as null
or have a value. Or change it to a type bit
and see what happens in each situation in the main darlings that you use.
These databases have an immeasurable amount of monitoring, statistics, profiling precisely because they are very useful and necessary.
Maybe in your case it’s not so necessary and the difference is so small that you shouldn’t even worry. If you have any bottleneck you’re probably somewhere else. And if you don’t, the worry is exaggerated. Think about it.
Particularly I would choose to have only the date until this proved problematic.
But if I keep only the date, I will have a field with null values (not excluded) and in this case it would not be possible to index, or it would be?
– Onaiggac
It depends on how you do it. But I don’t see why you couldn’t index. Existence of nulls doesn’t prevent indexing. I don’t see why the existence of an extra field is going to help. " I don’t see" doesn’t mean I don’t have it, I might just not be seeing it, maybe because I don’t know exactly what you’re doing. Anyway you already have it today. And I haven’t even said if it’s not worth you using filtered indices because I don’t know if it would be useful to you in this case.
– Maniero