Dmitri Kuzmenko wrote:
это я согласен, достаточно вспомнить ambiguous queries, и другие чудеса парсера. однако при несоответствии типов мы в большинстве случаев в tdatetime получим вовсе не то, что хранится в timestamp или time, если те хранят данные с миллисекундами.
Именно. Просто основная область применения - АСУП, где на это дело накласть с высокой вышки без передышки. Все натыкаются когда пытаются использовать не по назначению. Разбираются и успокаиваются. Я тоже об этом не задумывался, пока однажды, ещё до того, как попытался применить в ПК лога, где он был нужен только для order by, не напоролись на казус - в какой-то из вспомогательных задач вытягивания данных из старой базы в новую в параметр одного запроса тыкалось таймштамп-поле из другого и в среднем одну запись из пары тысяч этот запрос не видел. Записи в СУБД идентифицируются ПК, это постулат. И ПК должен быть интегер или на худой конец чар. Все атрибутные условия where - так или иначе диапазонные, включая starting-containing. Иногда бывает на равенство, но опять же по интам или чарам, остальное от лукавого. Так же как нулл по логике вещей нужен только в датах. Кроме очевидных правил есть и не совсем очевидные, воспринимаемые как рекомендации, но если копнуть поглубже - то всё обусловлено и детерминировано.
-- Regards. Ded.
