SS
хотя. тоже есть траблы конечно...
Size: a a a
2021 February 22
БГ
Честно говоря не ожидал что запрос который в скулайте отрабатывал исправно будет кривым для постгреса
Была некоторая надежда на то что "SQL есть SQL!")
W
Честно говоря не ожидал что запрос который в скулайте отрабатывал исправно будет кривым для постгреса
SQLite очень много стандартов не поддерживает или плюет на них. И это сделано специально.
W
То есть есть логическое объяснение - почему так.
YS
а что можете сказать по поводу H2? довольно распространенно среди разработчиков. для локального тестирования
Я про него ничего не знаю / не сталкивался, извините.
И насчёт распространённости — хоть даже https://db-engines.com/en/ranking
И насчёт распространённости — хоть даже https://db-engines.com/en/ranking
R
Была некоторая надежда на то что "SQL есть SQL!")
Оно то так, но некоторые СУБД отступают от стандарта (местами внося свои расширения, но бывают и грубые отступления и вот эта "фишка" с группировкой не по всем полям, которые не обёрнуты агрегатной функцией - пример грубого отступления)
YS
Честно говоря не ожидал что запрос который в скулайте отрабатывал исправно будет кривым для постгреса
Можете в любой распространённой СУБД его попробовать, если любопытно — так же "свалится" (с подобной ошибкой).
Хоть вот тут: https://dbfiddle.uk/
Хоть вот тут: https://dbfiddle.uk/
YS
Оно то так, но некоторые СУБД отступают от стандарта (местами внося свои расширения, но бывают и грубые отступления и вот эта "фишка" с группировкой не по всем полям, которые не обёрнуты агрегатной функцией - пример грубого отступления)
Все СУБД отступают от стандарта, местами нарушая его, по разным причинам.
А вот sqlite когда-то содрал это с MySQL "по старой памяти" поддерживает всякое странное. ;)
А вот sqlite когда-то содрал это с MySQL "по старой памяти" поддерживает всякое странное. ;)
S
Yaroslav Schekin
Не за что. ;) И почитали бы Вы https://wiki.postgresql.org/wiki/Don%27t_Do_This насчёт типов полей, использования serial...
получилось,ещё раз спасибо 👍
БГ
Оно то так, но некоторые СУБД отступают от стандарта (местами внося свои расширения, но бывают и грубые отступления и вот эта "фишка" с группировкой не по всем полям, которые не обёрнуты агрегатной функцией - пример грубого отступления)
В общем-то нынешнюю версию запроса можно отправлять фтопку и переписывать заново
БГ
Скромный вопрос.
ORM ругается на то что запрос не корректен, хотя ровно тот же запрос на sqlite выполнялся без особых вопросов.
Это ORM попусту возникает или в PostgreSQL такой запрос действительно не выполнится?
ORM ругается на то что запрос не корректен, хотя ровно тот же запрос на sqlite выполнялся без особых вопросов.
Это ORM попусту возникает или в PostgreSQL такой запрос действительно не выполнится?
Небольшое пояснение:
Запрос, по идее, должен выбрать все переписки по user.id, для каждой переписки выбрать последнее сообщение и дополнить его id и name юзера с которым беседа (не того переписки которого выбираются)
То есть чтобы исправить это нужно группировку делать не по interlocutor, т.к. это не позволяет СУБД, так?
Запрос, по идее, должен выбрать все переписки по user.id, для каждой переписки выбрать последнее сообщение и дополнить его id и name юзера с которым беседа (не того переписки которого выбираются)
То есть чтобы исправить это нужно группировку делать не по interlocutor, т.к. это не позволяет СУБД, так?
SS
а чего вы так извращаетесь?
SS
проще можно сделать
SS
но это уже наверно не к теории СУБД относится
БГ
а чего вы так извращаетесь?
Как обычно - от незнания)
БГ
проще можно сделать
Это как, например?
SS
ну я вам бы советовал 2 разных запроса сделать - один на "from..." и другой "to...". также по СУБД разбить их, на разные таблицы. мало ли что там в будущем будет. и в коде(Hibernate жава или .нет тоже разделить). ну а запросы из этих таблиц делать не проблема - даже в самых сложных ситуациях можно view сделать и на нее замапится.
SS
users:
id: int primary,
ip: text uniq,
name: text uniq
messages:
id: int primary,
from_id: int FK users.id,
to_id: int FK users.id,
text: text
даже не так. я бы вам посоветовал таблицу сообщений разделить - на входяшие и исходящие
БГ
даже не так. я бы вам посоветовал таблицу сообщений разделить - на входяшие и исходящие
Но ведь то что для одного юзера входящее то для другого исходящее
SS
ну и возможно стоит подумать насчет партиционирования. зависит от обьема и кол-ва сообщений