значит - WAF, строгие ACL для админских функций, md5 проверка кода на модификацию и репорт sql-ошибок в телеграм

и никогда никогда никогда не показывать их на продакшне)

А если в двух словах, то как сделать репорт sql-ошибок в телеграм?

Какая-то магия, или просто грепаем текстовый лог и шлем в бота по хттп?

ну у нас в rsyslogd пишется, а дальше подхватывается уже на сборщике

можно в аппликухе ловить ошибку и ставить в очередь отправки любой наколенный велосипед работает неплохо

пока аппов 1-3

В простейшем случае просто шлем. Но если ошибок будет 100500 в секунду то телефон умрет от вибрации

100500 ошибок в SQL - это прям ОЧЕНЬ плохой код и валидация)

Ну, это одна ошибка на странице, а на страницу например заходят 10 человек в секунду.

мы с примерно 16М хитов в сутки имеем 1-5 репортов

вкключая таймауты, ошибки валидации и всё такое

(я имею в виду веб-страницу в вакууме)

Ну тогда ок

то есть мы вообще сыпем в тим-чат php-фаталы, sql-фаталы и т.п.

но это требует внимания к коду

php-warnings тоже сыпем, остальное группируем и присылаем раз в сутки

Было бы наверно здорово иметь telegram foreign wrapper

за 5 лет один раз наловили blind sql, товарища отрезали в течение 2 минут с продакшна

не успел он ничего сделать

сегодня поднималась тема как финансовые данные хранить в базе. а у кого-то есть более серьезный материал? для банка/биржи например

В виде таблиц что ли?

В виде таблиц что ли?

не только. вообще архитектура

Архитектура чего?

Это чат о РСУБД... Какая тут архитектура может быть, кроме БазыДанныхВеликойИУжасноуВСамомЦентре !

сегодня поднималась тема как финансовые данные хранить в базе. а у кого-то есть более серьезный материал? для банка/биржи например

Подумай ещё раз хорошо, в чем суть твоего вопроса , если ты задаёшься им в контексте обсуждения реляционной БД.

Подумай ещё раз хорошо, в чем суть твоего вопроса , если ты задаёшься им в контексте обсуждения реляционной БД.

это не вопрос. я ищу рецепты хорошей архитектуры для финансовых транзакций

может есть видео хорошие, книжки

че-то стоящее, а не 20 слайдов

это не вопрос. я ищу рецепты хорошей архитектуры для финансовых транзакций

Его нет

это не вопрос. я ищу рецепты хорошей архитектуры для финансовых транзакций

Все зависит от твоего ТЗ, которое знаешь только ты.

может есть видео хорошие, книжки

Книги и слайды есть, но они будут по то, как какие-то люди решали свои задачи, а по то, как ты будешь решать свою, книг и фильмов ещё нет. Ты можешь написать, когда решишь.

Книги и слайды есть, но они будут по то, как какие-то люди решали свои задачи, а по то, как ты будешь решать свою, книг и фильмов ещё нет. Ты можешь написать, когда решишь.

мне для биржи надо

это не вопрос. я ищу рецепты хорошей архитектуры для финансовых транзакций

а в чем разница ну что финансовые что любые другие ._. ну если оно конечно логически в транзакцию помещаются

просто скиньте книги

храни все в decimal, какая еще теория нужна?)

мне для биржи надо

Какой биржи? В общем, для начала сделать нормализованную схему исходя из требований.

а то что размер четко 16 метров ничего не значит, он аллоцируется при создании сегмента и инициализируется нулями

Спасибо за ответ!

храни все в decimal, какая еще теория нужна?)

Если ему ФИНАНСОВЫЕ ДАННЫЕ надо хранить, то можно и во float. А порой и нужно.

почему во float?

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

Если ему ФИНАНСОВЫЕ ДАННЫЕ надо хранить, то можно и во float. А порой и нужно.

А мне вот тут неоднократно говорили и говорят, что деньги нужно хранить в numeric с заданной точностью после запятой.

А мне вот тут неоднократно говорили и говорят, что деньги нужно хранить в numeric с заданной точностью после запятой.

Тоже придерживаюсь такой позиции

Тем более, что понимание, что такое float (double) в машинном исполнении, есть. Хоть и и давался этот материал то ли на втором, то ли на третьем курсе (1995-1996 гг.). Но как-то вот врезался. Хоть сильно и не трясли нас на том курсе.

можно же и просто в инт хранить, не?

типу, миллион копеек ))

проценты будет потом тяжело считать

почему?

потому что будет дробная часть

просто не будем делить одну копейку на троих ))

Тут скорее за приведение типов

разбейте 2000 рублей на три позиции и найдите еще налог для каждой позиции

классичекий пример: кассовый чек в магазине, где есть позиции и НДС для каждой и все это должно биться в тотале

А мне вот тут неоднократно говорили и говорят, что деньги нужно хранить в numeric с заданной точностью после запятой.

Правильно говорят. Но ФИНАНСОВЫЕ данные — это не деньги.

классичекий пример: кассовый чек в магазине, где есть позиции и НДС для каждой и все это должно биться в тотале

Оно не должно с чем-то биться. Ты ошибаешься.

Оно не должно с чем-то биться. Ты ошибаешься.

расскажи мне занимательные истории

эТо ты мне расскажи, что с чем должно биться? В позиции чека есть товар с ценой. цены складываются, получается сумма чека. Там даже НДС нет.

давно в чек смотрел?

Допустим, он бы там был, как в США, или как в счетах фактуры. В позиции есть стоимость товара без НДС и с НДС (возможно, округлённая) По чеку ты получешь две суммы (суммированием двух сумм из позиций) без НДС и с НДС. Что с чем биться должно?

Там даже реквизиты чека в фнс есть

http://online-kassa.pro/zakon/chek-onlajn-kassy.html

давно в чек смотрел?

Так что с чем биться должно? Расскажешь?

после таких расчетов налогавая вас начинает дрюкать

Еще можно вспомнить задачи из телекома, когда надо АП за месяц раскидать на дни и там такие же проблемы начинаются

после таких расчетов налогавая вас начинает дрюкать

Ключевое слово — ВАС... А нас — нет.

ой всё

ты как всегда

ой всё

Вот именно.

Потом напиши свои истории успеха расчета процентов

Ключевое слово — ВАС... А нас — нет.

а можно вернуться в констркутивное русло?

а можно вернуться в констркутивное русло?

Это тяжело. Бухгалтерия и налоговая отрицают математику.

Вот хороший пример вспомнил, есть услуга за 100 рублей АП в месяц, надо рассчитывать ежедневное списание с налогами соответственно

Привет всем! Не подскажите есть у кого опыта создания файлового хранилища на Postgre? В MS SQL есть filestream, который сбрасывает файл в файловую систему, но позволяет бекапить и тд. В Postgre, как я понимаю, такого нет. Есть лишь blob (lagre objects) и bytea, причем после создания TOASTED скорость bytea стала сопоставимой с blob. Справиться ли база, если в ней будет 200 или 300 гб файлов (считай в одной таблице)? И все в таком духе

Вот хороший пример вспомнил, есть услуга за 100 рублей АП в месяц, надо рассчитывать ежедневное списание с налогами соответственно

А НДС тут при чём?

А НДС тут при чём?

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

Привет всем! Не подскажите есть у кого опыта создания файлового хранилища на Postgre? В MS SQL есть filestream, который сбрасывает файл в файловую систему, но позволяет бекапить и тд. В Postgre, как я понимаю, такого нет. Есть лишь blob (lagre objects) и bytea, причем после создания TOASTED скорость bytea стала сопоставимой с blob. Справиться ли база, если в ней будет 200 или 300 гб файлов (считай в одной таблице)? И все в таком духе

не делал, не знаю логично предположить что лучше файлы держать в файлах, и пыхать картинки в субд - не лучший алгоритм по быстродействию

Увы, файловую систему юзать не получается так как (по определенным причинам) резко против админы

Главная причина - легкий бекап, который можно сделать через БД

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

Нет, не будут. У тебя есть формула, как вычислять процент (Т.е. часть) и как суммировать эти проценты, Всё чётко и без погрешностей.

Главная причина - легкий бекап, который можно сделать через БД

то есть лень )

Нет, не будут. У тебя есть формула, как вычислять процент (Т.е. часть) и как суммировать эти проценты, Всё чётко и без погрешностей.

да да, а выше мой пример это ошибки экселя

то есть лень )

Ну пусть будет так. В любом случае - был ли у кого-то опыт создания такого на Postgre? Количество баз можно будет потом сделать любое, но одна база с скажем 300Гб данных должна работать нормально

То есть чтобы чтение не занимало 30 секунд

Привет всем! Не подскажите есть у кого опыта создания файлового хранилища на Postgre? В MS SQL есть filestream, который сбрасывает файл в файловую систему, но позволяет бекапить и тд. В Postgre, как я понимаю, такого нет. Есть лишь blob (lagre objects) и bytea, причем после создания TOASTED скорость bytea стала сопоставимой с blob. Справиться ли база, если в ней будет 200 или 300 гб файлов (считай в одной таблице)? И все в таком духе

https://wiki.postgresql.org/wiki/BinaryFilesInDB с точки зрения ресурсов лучше блобы. Упрощение бекапа усложняет код.

Это я видел, но даже взять блобы. У кого-то есть опыт реального использования на те же 300 Гб?

У меня есть. К сожалению. Работать это будет, но сразу надо кодить всё на случаи "так, а что у нас в этом файле" или "а достань-ка этот файл из базы и скинь мне на почту".

То есть файл менеджер

Н у и, естественно, по скорости и нагрузке это всё равно будет сильно проигрыать варианту с хранением в базе пути и раздачей файлов через nginx, например.

Пока у вас есть ещё возможность не стрелять себе в ногу, лучше потратить запланированные на разработку этого время на убеждение админов.

А можете конкретные цифры привести? Ну там полное чтение файла в 100 кб сколько занимает?

ну не скажу уже. 100 кб не так уж много

под рукой этой базы уже нет славтехосспидя

дело не столько в том, сколько времени занимает чтение этого файла из базы, соклько в том, сколько ресурсов отжирается на этот процесс в целом

хотя если у вас десяток пользователей, то пофиг

Ну будет где-то 10-20 одновременных подключений