в вашем случае и valid_until и created_at берутся у одной и той же записи. Т.е. логически это действует так: выбираются все строки, где valid_until > created_at, а потом среди них смотится, есть ли повторы юзеров. Т.е. бессмыслица, так как valid_until > created_at это true для всех записей.
Exclude же проверяет, есть ли другие записи, которые пересекаются по диапазону со вставляемой записью
на практике я не раз встречал ситуацию, когда отсутствие unique или foreign key приводили к проблемам. И наоборот: не вижу особой проблемы добавить exclude
В общем, это зависит от конкретики, я бы не обобщал и не делал бы из этого глобального правила
По сути - это вопрос о том, зачем вообще нужны констрейнты бд. Те же Unique, Foreign key и т.д.
Это просто дополнительная защита от случайных ошибок. Например, в одном месте при выдаче купонов учли момент с уникальностью, а в другом (при массовом импорте купонов ) - нет. И тогда будет хаос.
Разумеется, всегда есть неважные места, где можно ничего не проверять на базе. А есть работа с деньгами, где лучше 3 раза перебдеть.
Признаюсь, элемент наброса есть. Дело в том, что скучную взвешенную душноту никто не читает. А так, на наезд набежало много народа, кучу ценных мыслей накинули. Я очень много почерпнул из обсуждений.
Т.е. мне правда голые запросы нравятся больше, но я готов подвинуться во мнении, если будут аргументы. И сегодня прям есть о чем подумать.
А то, что там начинается магия по автоматической генерации запросов, эти запросы бывают весьма странны. Видел на своей практике запросы вида where id in (...1000500 разных id... ) и много другого весёлого.
Или когда программист в цикле пишет user->posts, то получает много-много запросов, потому что при магическом взаимодействии очень просто ошибиться.
это выражение дает не ложь, а null
спасибо, отметил в статье, что триггер надо дорабатывать
в вашем случае и valid_until и created_at берутся у одной и той же записи. Т.е. логически это действует так: выбираются все строки, где valid_until > created_at, а потом среди них смотится, есть ли повторы юзеров. Т.е. бессмыслица, так как valid_until > created_at это true для всех записей.
Exclude же проверяет, есть ли другие записи, которые пересекаются по диапазону со вставляемой записью
на практике я не раз встречал ситуацию, когда отсутствие unique или foreign key приводили к проблемам. И наоборот: не вижу особой проблемы добавить exclude
В общем, это зависит от конкретики, я бы не обобщал и не делал бы из этого глобального правила
ну ок )
По сути - это вопрос о том, зачем вообще нужны констрейнты бд. Те же Unique, Foreign key и т.д.
Это просто дополнительная защита от случайных ошибок. Например, в одном месте при выдаче купонов учли момент с уникальностью, а в другом (при массовом импорте купонов ) - нет. И тогда будет хаос.
Разумеется, всегда есть неважные места, где можно ничего не проверять на базе. А есть работа с деньгами, где лучше 3 раза перебдеть.
Триггер я написал лишь примерно, просто как иллюстрацию. Вообще, его, конечно нужно доработать и отдебажить
Да, так лучше, переделаю чуть позже, спасибо
Это неверно просто.
https://habr.com/ru/articles/448072/
https://habr.com/ru/articles/450528/
Признаюсь, элемент наброса есть. Дело в том, что скучную взвешенную душноту никто не читает. А так, на наезд набежало много народа, кучу ценных мыслей накинули. Я очень много почерпнул из обсуждений.
Т.е. мне правда голые запросы нравятся больше, но я готов подвинуться во мнении, если будут аргументы. И сегодня прям есть о чем подумать.
Если переход на другую БД очень вероятен, то конечно надо использовать ORM
а главное, синтаксис становится жутковат, гораздо хуже SQL
А то, что там начинается магия по автоматической генерации запросов, эти запросы бывают весьма странны. Видел на своей практике запросы вида
where id in (...1000500 разных id... ) и много другого весёлого.
Или когда программист в цикле пишет user->posts, то получает много-много запросов, потому что при магическом взаимодействии очень просто ошибиться.
более сложный для чтения язык запросов, подкапотная магия по построению SQL-запросов
ну вот увидел я в логе какую-то дичь, что дальше делать?
это валидный аргумент, спасибо
да, от языка точно зависит, очень много хорошего слышал про c#
а зачем squirrel рефлексия?
для простых CRUD можно что угодно использовать, но редко бывают приложения из простых CRUD
если нет тестов, то опечатка - не самое страшное. Если есть тесты, то опечатка не проблема