> On Oct 20, 2025, at 5:05 AM, Peter J. Holzer <[email protected]> wrote:
>
> On 2025-10-19 20:32:07 -0600, Rob Sargent wrote:
>>>> On Oct 19, 2025, at 2:38 PM, Rich Shepard <[email protected]> wrote:
>>> On Sun, 19 Oct 2025, Rob Sargent wrote:
>>>> I think you have to ask why those values were separated in the first
>>>> place. For instance if they are thought of as a pair in most queries then
>>>> an alteration might be in order. There can be a large one time cost if
>>>> these tables occur in a lot of separate sql calls in the business logic.
>>>
>>> Good point. They're in the contacts table and I use them to determine when
>>> to make another contact and if prior contacts were more productive in the
>>> morning or afternoon.
>>
>> Definitely a datetime (single value) problem, imho
>
> Actually, to me that seems to be one of the few cases where splitting
> them makes sense. I would expect typical updates to be something like
> "sane time, but 6 months later" or "same day, but different time". There
> might also be constraints like "not before 9am". For queries there might
> be stuff like "who do I need to call today", or as Rich already
> mentioned, statistics by time of the day. There are probably relatively
> few queries where you need to treat date and time as a unit.
>
> hjp
I don’t see any mention of the current data types of the two columns currently
in play. apologies of I missed that.
Which of your example updates cannot be done with timestamp? Perhaps the “not
before”constraint but can that be done with OP’s design? Maybe the time column
is an interval?
>
> --
> _ | Peter J. Holzer | Story must make more sense than reality.
> |_|_) | |
> | | | [email protected] | -- Charles Stross, "Creative writing
> __/ | http://www.hjp.at/ | challenge!"
> <signature.asc>
