@pgsql

Страница 633 из 1062
 
Александр
16.01.2018
09:10:26
Ну будет где-то 10-20 одновременных подключений
это ты сейчас так думаешь а если продукт разойдётся чуть шире - получишь 100к, что тогда?

 
Vladislav
16.01.2018
09:10:40
о, да, я бы с удовольствием с каждой транзакции имел бы по копейки, никто же не заметит

 
Rustam
16.01.2018
09:11:19
это ты сейчас так думаешь а если продукт разойдётся чуть шире - получишь 100к, что тогда?
Да, тогда жопа. Мне тоже мягко говоря не нравится все задумка и система получиться не расширяемой.

 
crux
16.01.2018
09:11:38
Ну будет где-то 10-20 одновременных подключений
Да хз, надо оценивать в том числе архитектуру приложения, возможные блокировки и т.д. В любом случае это затратный процесс, который будет держать базу. Это плохо, плохо, плохо.

Google
 
Rustam
16.01.2018
09:12:35
Спасибо большое за ответы. В общем я зашел просто убедиться, что это настолько же плохо в реальности как это видится мне( Видимо и правда идея очень плохая

 
crux
16.01.2018
09:12:46
она даже хуже

 
Vladislav
16.01.2018
09:13:25
Но мы ж не об этом всём, это — бухгалтерские приложения, там как раз точность нужна до копейки. А вот в ФИНАНСОВЫХ приложениях всякие показатели типа оборот, прибыль, и т.п. — это не деньги в чистом виде, это финансовые показатели, там +- копейка никому не важна. Там часто считают по приблизительным формулам, и туда или сюда тдна тысяча рублей никого не смутит, поскольку это обычно ПРЕДПОЛАГАЕМЫЕ, или ПРИМЕРНО РАСчИТЫВАЕМЫЕ показатели. Там важны порядки значений, а не значения с точностью до копейки. ИМЕННО ПОЭТОМУ финансовые (не бухгалтерские) расчёты МОЖНО делать в типах с плавающей точкой. ЕСТЕСТВЕННО, всё это должно выясняться при постановке задачи.
Вспоминаю, как раз вот такое, не учли округление и налоги и спустя пару месяцев на транзакциях образовалась разница почти в 100к$ доходов компании. Никто не заметит? Погрешность?

 
Mike Chuguniy
16.01.2018
09:29:41
Ну так что, чеки актуальны? У меня есть парочка штук.

 
Ilia
16.01.2018
09:30:43
Вспоминаю, как раз вот такое, не учли округление и налоги и спустя пару месяцев на транзакциях образовалась разница почти в 100к$ доходов компании. Никто не заметит? Погрешность?
Блин, ты вообще что-либо ЧИТАТЬ в состоянии ?

 
Taras ?
16.01.2018
09:34:16
Вспоминаю, как раз вот такое, не учли округление и налоги и спустя пару месяцев на транзакциях образовалась разница почти в 100к$ доходов компании. Никто не заметит? Погрешность?
карманные деньги))

 
Vladislav
16.01.2018
09:36:02
Блин, ты вообще что-либо ЧИТАТЬ в состоянии ?
Умею, и опыт имею таких проблем в телекоме и в фарме на разных платформах и базах. Поэтому не надо мне рассказывать сказки

 
Nikolai
16.01.2018
09:37:20
округления и налоги - большая-большая боль поэтому мы первый раз всегда округляем в большую сторону))

 
и храним счетчики "недостачи", которые обновляем регулярно и довыставляем

 
Darafei
16.01.2018
09:39:25
а не придумал ли кто тип для хранения дробей, в котором был бы и числитель и знаменатель?

 
чтобы 1 / 3 нормально хранить

 
Denis
16.01.2018
09:40:41
и чтобы сами сокращались

 
Vladislav
16.01.2018
09:41:01
и храним счетчики "недостачи", которые обновляем регулярно и довыставляем
Да, один из вариантов, это хранить остатки и пересчитывать их постоянно, подбивая значения. Благодаря таким действиям погрешность будет гораздо меньше на свежих данных, а после проведения биллинга все будет биться

Google
 
Vladislav
16.01.2018
09:41:35
чтобы 1 / 3 нормально хранить
Один раз видел такое, просто два поля хранили, но для чего и как работало, не в курсе...

 
Nikolai
16.01.2018
09:42:06
мы так и делаем как раз а засчет первого округления вверх у нас маржинальность "дрожит", но мы в-целом в плюсах по МО так как у нас платежи от физиков и EULA это позволяет, то всё четко

 
может есть способ это сделать более красиво, конечно, но я его не знаю

 
Darafei
16.01.2018
09:42:58
кто запилит сишный тип для такого? :)

 
Konstantin
16.01.2018
09:44:29
Можно в point-е хранить (только хранить, арифметики никакой конечно не будет) или самому тип написать.

 
Darafei
16.01.2018
09:52:11
в point-е будет два дабла, а мне кажется, что через полгода переходящих расчётов знаменатель у такой штуки может и перевалить по битности за мантиссу дабла

 
Konstantin
16.01.2018
09:55:01
Ну тыда через год и за int64 перевалит:) Тогда тебе нужна пара numeric-ов, но арифметика над ними работать будет со скоростью арифмометра. Алгоритм Евликада над numericами - это не хухры-мухры.

 
Darafei
16.01.2018
09:55:38
ну, или хранить как разложение на простые сомножители

 
массив сомножителей числителя, массив сомножителей знаменателя

 
Konstantin
16.01.2018
09:57:05
Зачем? Разложение на простые множители - это гораздо более сложная задача чем нахождение НОД, нужного для нормализации

 
Если у тебя не могут возникнуть слишком большие числа, то храни в point-е, делай нормализацию с помощью Евликада после каждой операции и ничего у тебя через пол года не переполнится.

 
Yaroslav
16.01.2018
10:20:23
Спасибо большое за ответы. В общем я зашел просто убедиться, что это настолько же плохо в реальности как это видится мне( Видимо и правда идея очень плохая
Вы в курсе, что сравниваете тёплое с мягким? Файлы, хранимые в СУБД, дают Вам full ACID, а вне её —- просто файлопомойка, без каких-либо гарантий. Если последнее Вам подходит, то, конечно, лучше хранить в виде файлов в FS.

 
Taras ?
16.01.2018
10:21:54
реплики файлов дают некую гарантию

 
Sergey
16.01.2018
10:25:21
реплика, имхо это про другое...

 
Yaroslav
16.01.2018
10:26:13
реплики файлов дают некую гарантию
"Некую"? Что это вообще значит? ;)

 
кто запилит сишный тип для такого? :)
http://dvarrazzo.github.io/pgmp/mpq.html видели?

 
Ilia
16.01.2018
10:34:07
округления и налоги - большая-большая боль поэтому мы первый раз всегда округляем в большую сторону))
Вы чё все что ли скопом? Где вы видили налоги в финансовых приложениях? Вы финансы писали когда-нибудь вообще? Не бухгалтерию, не склады, а финучёт.

 
Nikolai
16.01.2018
10:34:52
комиссии

 
от комиссии, от комиссии и ещё раз от комиссии

 
с фиксами, прямыми и обратными процентами в одной формуле

Google
 
Nikolai
16.01.2018
10:35:20
с расчетом чистой, грязной прибыли и себестоимости операции

 
каждый божий день это считаем сотнями транзакций

 
я конечный автомат статусов заказов и цепочки комиссий вижу в ночных кошмарах

 
суть комиссии в % от суммы эквивалентна налогу (но только не в пользу государства бгг)

 
теперь добавьте сюда отчисления партнёрам (в %) от суммы чистой прибыли у нас получается в самой длинной цепочке 5 разных изменений суммы в процентах сначала в одну сторону, потом в другую причем партнёры, считающие окупаемость трафика впадают в раж при несовпадениях в копейки - потому что они могут на оффере зарабатывать как раз те самые копейки, но брать потоком

 
Taras ?
16.01.2018
10:38:11
"Некую"? Что это вообще значит? ;)
вероятность потери файла при наличии 5-7 копий стремится к нулю

 
Yaroslav
16.01.2018
10:39:04
вероятность потери файла при наличии 5-7 копий стремится к нулю
Вероятность потери —- это только "D" из ACID, вот в чём дело.

 
Taras ?
16.01.2018
10:44:20
Вероятность потери —- это только "D" из ACID, вот в чём дело.
эээ, я ведь нуб зеленый)) многого и не знаю вообще, только учусь

 
Айтуар
16.01.2018
13:38:41
Это я видел, но даже взять блобы. У кого-то есть опыт реального использования на те же 300 Гб?
1ТБ таблица с файлами. Но они не явно там сидят, а в запросах. Там в поле хранится запрос который содержит файлы прикреплённые к веб запросу. Но эта таблица играет роль логирования т.е. в неё больше пишут.

 
Aw
16.01.2018
13:49:58
1ТБ таблица с файлами. Но они не явно там сидят, а в запросах. Там в поле хранится запрос который содержит файлы прикреплённые к веб запросу. Но эта таблица играет роль логирования т.е. в неё больше пишут.
Это кто же такую "гениальную" систему придумал?

 
Айтуар
16.01.2018
13:55:11
Это кто же такую "гениальную" систему придумал?
Ну разрабы. Хуяк и продать. Кто изначально думал про рост БД. Никто. Сейчас спасает только партиции.

 
Alex
16.01.2018
14:46:29
Это я видел, но даже взять блобы. У кого-то есть опыт реального использования на те же 300 Гб?
Аккуратнее надо, тк в пг можно данные типа bytea положить, а обратно уже не вынуть. Лучше наверное пользовать для бинарных данных large objects

 
база справляется и с терабайтными таблицами с той же bytea

 
только есть ньюансы с bytea размером больше 300 мб

 
что их например pg_dump не могет забекапить, copy не может выгрузить в том же escape формате

 
кароче аккуратнее

 
large objects хорош тем что например позволяет делать seek на файл и например по кусочкам его грузить

 
а bytea сразу целиком только предоставляется

 
Rustam
16.01.2018
14:52:08
Если в кратце ответ таков - не надо хранить файлы в БД) Ну это если суммировать ответы всех)

 
Александр
16.01.2018
14:52:54
По ходу да

Google
 
Александр
16.01.2018
14:53:39
А кто что использует для хранения файлов пользователей?

 
Хотя вопрос не в тот чат, наверн)

 
Сергей
16.01.2018
14:58:50
диск) или хранилища гугловые/амазоновские

 
я вообще хз кто хранит файлы в базе

 
Alexey
16.01.2018
15:01:47
Large object чем плох?

 
Darafei
16.01.2018
15:02:21
хороший вопрос на собеседование - "что лучше: хранить базу в файлах или файлы в базе?"

 
Dmitry
16.01.2018
15:03:04
файлы базы в базе в файлах

 
Ilia
16.01.2018
15:03:16
хороший вопрос на собеседование - "что лучше: хранить базу в файлах или файлы в базе?"
Лучше сразу: что было раньше, курица или яйцо?

 
Mike Chuguniy
16.01.2018
15:06:51
Лучше сразу: что было раньше, курица или яйцо?
Раньше было всё!

 
Alexey
16.01.2018
15:15:52
Сильно large object уступает по доступу/отдаче, чем напрямую в fs?

 
Сергей
16.01.2018
15:20:08
Сильно large object уступает по доступу/отдаче, чем напрямую в fs?
ты лишаешься всех прелестей отдачи файлов через веб-сервер

 
Ilia
16.01.2018
15:20:25
Раньше было всё!
Кстати, хороший ответ!

 
Leonid
16.01.2018
15:28:49
А чем благородные доны ходят в postgres чтоб запросы задавать с автодополнением и в результаты глазами смотреть? psql в консоли как-то неудобно, от datagrip опернсурцная лицензия протухла (а 200$/year жалковато), а у нового браузерного pgadmin какие-то детские проблемы с неумением прервать запрос и эпизодической потерей введённого текста.

 
Rustam
16.01.2018
15:30:35
У dataGrip есть еще один большой минус - он не могет работать больше, чем с одной базой одновременно. То есть 1 connection = 1 база

 
Mike Chuguniy
16.01.2018
15:31:12
А что не так у psql с автодополнением?

 
Leonid
16.01.2018
15:31:52
@Chuguniy с ним всё в порядке, но больше двух колонок в терминале как-то видеть совсем печально.

 
Mike Chuguniy
16.01.2018
15:32:05
А то я именно для зайти в БД, чего-нибудь быстро-быстро глянуть что-либо лучше плохо себе представляю.

 
Аггей
16.01.2018
15:32:29
@Chuguniy с ним всё в порядке, но больше двух колонок в терминале как-то видеть совсем печально.
\x

 
Mike Chuguniy
16.01.2018
15:32:33
@Chuguniy с ним всё в порядке, но больше двух колонок в терминале как-то видеть совсем печально.
Терминал по ширине на весь экран развернуть? Не?

 
Ну или \x, да

Google
 
Arthur
16.01.2018
15:43:04
@Chuguniy с ним всё в порядке, но больше двух колонок в терминале как-то видеть совсем печально.
https://github.com/okbob/pspg

 
Александр
16.01.2018
15:44:24
А чем благородные доны ходят в postgres чтоб запросы задавать с автодополнением и в результаты глазами смотреть? psql в консоли как-то неудобно, от datagrip опернсурцная лицензия протухла (а 200$/year жалковато), а у нового браузерного pgadmin какие-то детские проблемы с неумением прервать запрос и эпизодической потерей введённого текста.
https://www.sqltabs.com

 
Он ещё умеет по результатам запроса строить графики или сводную таблицу Отлично помогает для анализа логов, просто наглядно видишь ускорение

 
Пользуюсь сим средством каждый день

 
+ прикольно раскрашивает план запроса)

 
Да графиков вместо ctrl+r (простой запуск запроса) используй ctrl+e - учтет команды в комментах

 
+ он умеет вводить результаты исполнения нескольких запросов

 
Ну и из дикого - есть автокомплит

 
При длинных названиях даже пользуюсь

 
Leonid
16.01.2018
15:48:43
Ну от \x тоже счастья не много. sqltabs прикольный, на первый взгляд чуть веселее, чем vim, \x и \e.

 
Александр
16.01.2018
15:48:53
Ха

 
Сравнил)

 
Kirill
16.01.2018
15:49:18
Вот такие функции нужно создать, чтобы pgadmin3 смог спокойно соединиться к PostgreSQL 10: create function pg_last_xlog_receive_location() returns text as $$ select pg_last_wal_receive_lsn()::text $$ language sql; create function pg_last_xlog_replay_location() returns text as $$ select pg_last_wal_replay_lsn()::text $$ language sql; create function pg_is_xlog_replay_paused() returns bool as $$ select pg_is_wal_replay_paused() $$ language sql;

 
Leonid
16.01.2018
15:52:32
@SanSYS А sqltabs server-side курсоры умеет или сразу всё в память грузит?

 
Aw
16.01.2018
15:54:04
Dbeaver юзаю бесплатный. Есть косяки с автоподсказками, но в целом нравится. С большими таблицами работает нормально, все не грузит в ОЗУ

 
Yaroslav
16.01.2018
15:54:32
Если в кратце ответ таков - не надо хранить файлы в БД) Ну это если суммировать ответы всех)
Если надо ACID —- храните, а нет —- так нет. ;)

 
Alex
16.01.2018
15:57:54
А чем благородные доны ходят в postgres чтоб запросы задавать с автодополнением и в результаты глазами смотреть? psql в консоли как-то неудобно, от datagrip опернсурцная лицензия протухла (а 200$/year жалковато), а у нового браузерного pgadmin какие-то детские проблемы с неумением прервать запрос и эпизодической потерей введённого текста.
89$ же для индивидуалов, в следующий год еще меньше

 
Darafei
16.01.2018
15:58:16
89$ же для индивидуалов, в следующий год еще меньше
и за багрепорты бесплатно

 
Aw
16.01.2018
15:58:28
Если надо ACID —- храните, а нет —- так нет. ;)
Понимаю человека, когда есть детище "умных мальчиков" и поменять его никак нельзя. Вариант либо вешать тригер на таблицу и писать по нормальному либо перехватывать сам insert и уже потом писать в нормальной форме.

Страница 633 из 1062