Size: a a a

DBA - русскоговорящее сообщество

2021 March 04

N

NoName in DBA - русскоговорящее сообщество
Ilia Zviagin
Бегай за проектами каждого юзера на базу
это же будет дофига запросов, разве никак нельзя оптимизировать это?
источник

АА

Андрей Агеев... in DBA - русскоговорящее сообщество
NoName
это же будет дофига запросов, разве никак нельзя оптимизировать это?
см. row_number() over(user_id)
источник

YS

Yaroslav Schekin in DBA - русскоговорящее сообщество
NoName
Postres
Может, всё-таки, postgres (или таки progress)? ;)
Посмотрите на LATERAL.
источник

IZ

Ilia Zviagin in DBA - русскоговорящее сообщество
NoName
это же будет дофига запросов, разве никак нельзя оптимизировать это?
Это НЕ будет дофига запросов. Запрос надо сдать только если пользователь захочет посмотреть именно проекты конкретного пользователя
источник

E

Etki in DBA - русскоговорящее сообщество
NoName
это же будет дофига запросов, разве никак нельзя оптимизировать это?
Подзапрос тебе нужен, а не запрос.
источник

N

NoName in DBA - русскоговорящее сообщество
Ilia Zviagin
Это НЕ будет дофига запросов. Запрос надо сдать только если пользователь захочет посмотреть именно проекты конкретного пользователя
не, есть страница с юзерами, и на этой странице у каждого юзера должна сразу показываться пачка его последних проектов, поэтому проекты надо сразу загружать
источник

IZ

Ilia Zviagin in DBA - русскоговорящее сообщество
NoName
не, есть страница с юзерами, и на этой странице у каждого юзера должна сразу показываться пачка его последних проектов, поэтому проекты надо сразу загружать
А зачем? Страница с юзерами? Показывай юзеров.
Ткнут в юзера — покажешь проекты.
источник

IZ

Ilia Zviagin in DBA - русскоговорящее сообщество
NoName
не, есть страница с юзерами, и на этой странице у каждого юзера должна сразу показываться пачка его последних проектов, поэтому проекты надо сразу загружать
50х20 = 1000 - там будут одни проекты, а не пользователи.
источник

N

NoName in DBA - русскоговорящее сообщество
Ilia Zviagin
А зачем? Страница с юзерами? Показывай юзеров.
Ткнут в юзера — покажешь проекты.
согласен, но хотят что бы так было
источник

IZ

Ilia Zviagin in DBA - русскоговорящее сообщество
NoName
согласен, но хотят что бы так было
"Хочется, — перехочется".
источник

BG

Bogdan Gerasymenko in DBA - русскоговорящее сообщество
Ребят, подскажите по хранению цен в базе данных.

Я ж правильно понимаю, идеальный тип - DECIMAL, потому что позволяет хранить цены с копейками (например 99.9)?

Но вот с чем столкнулся - при таком типе почему-то происходит округление - вместо 99.5 в базу сохраняет 100, хотя стоит decimal(10,2) - от куда берется округление?

При decimal(10,0) округление не происходит, но дописываются два нуля после запятой, даже если их не ставить.

Собственно вопрос, как сделать так, чтобы хранило и целые числа 99 и дробные 99.5 и ничего не округляло, не дописывало нули если их не нужно? Поставить тип longtext?
источник

IK

Igor Komarov in DBA - русскоговорящее сообщество
Bogdan Gerasymenko
Ребят, подскажите по хранению цен в базе данных.

Я ж правильно понимаю, идеальный тип - DECIMAL, потому что позволяет хранить цены с копейками (например 99.9)?

Но вот с чем столкнулся - при таком типе почему-то происходит округление - вместо 99.5 в базу сохраняет 100, хотя стоит decimal(10,2) - от куда берется округление?

При decimal(10,0) округление не происходит, но дописываются два нуля после запятой, даже если их не ставить.

Собственно вопрос, как сделать так, чтобы хранило и целые числа 99 и дробные 99.5 и ничего не округляло, не дописывало нули если их не нужно? Поставить тип longtext?
Вообще больше похоже на то, что нужно бы форматировать на стороне морды...
источник

BG

Bogdan Gerasymenko in DBA - русскоговорящее сообщество
Igor Komarov
Вообще больше похоже на то, что нужно бы форматировать на стороне морды...
так и есть) в базу сохраняется уже обработанное число, тут вопрос в каком типе хранить данные)
источник

IK

Igor Komarov in DBA - русскоговорящее сообщество
Bogdan Gerasymenko
так и есть) в базу сохраняется уже обработанное число, тут вопрос в каком типе хранить данные)
Взять правильный тип: decimal(10, 2). И дальше на стороне морды форматировать как душе угодно: отрезать нули / не отрезать нули, округлять / не округлять

На скрине пример.
источник

BG

Bogdan Gerasymenko in DBA - русскоговорящее сообщество
Спасибо 👍
источник

K

Konstantin in DBA - русскоговорящее сообщество
постгресяне, подскажите плз синтаксис для подобного условия
DECLARE
   tst TEXT [] DEFAULT ARRAY ['a', 'b'];
BEGIN
   IF 'a' IN history_tables THEN
т.е. хочу проверить что что-то содержится в массиве
п.с. затык в 4 строке
источник

К

Какой-то Хмырь... in DBA - русскоговорящее сообщество
Konstantin
постгресяне, подскажите плз синтаксис для подобного условия
DECLARE
   tst TEXT [] DEFAULT ARRAY ['a', 'b'];
BEGIN
   IF 'a' IN history_tables THEN
т.е. хочу проверить что что-то содержится в массиве
п.с. затык в 4 строке
if 'a' = ANY (array)
вроди
источник

К

Какой-то Хмырь... in DBA - русскоговорящее сообщество
еще так можно -
if array @> '{"a", "b"}' если надо сразу несколько значений передать


вот тут примеры есть
https://www.postgresql.org/docs/current/functions-array.html
источник

K

Konstantin in DBA - русскоговорящее сообщество
Какой-то Хмырь
if 'a' = ANY (array)
вроди
то что надо, спасибо огромное!)
источник

IZ

Ilia Zviagin in DBA - русскоговорящее сообщество
Bogdan Gerasymenko
Ребят, подскажите по хранению цен в базе данных.

Я ж правильно понимаю, идеальный тип - DECIMAL, потому что позволяет хранить цены с копейками (например 99.9)?

Но вот с чем столкнулся - при таком типе почему-то происходит округление - вместо 99.5 в базу сохраняет 100, хотя стоит decimal(10,2) - от куда берется округление?

При decimal(10,0) округление не происходит, но дописываются два нуля после запятой, даже если их не ставить.

Собственно вопрос, как сделать так, чтобы хранило и целые числа 99 и дробные 99.5 и ничего не округляло, не дописывало нули если их не нужно? Поставить тип longtext?
Понимаешь правильно.

Округления не бывает, ты что-то сделал не так, что-то сделал неправильно.
источник