Рубрика «базы данных» - 10

Периодически у разработчика возникает необходимость передать в запрос набор параметров или даже целую выборку «на вход». Иногда попадаются очень странные решения этой задачи.

Пойдем «от обратного» и посмотрим, как делать не стоит, почему, и как можно сделать лучше.
Читать полностью »

От переводчика: в ходе моей работы в нигерийском финтехе пришлось мне создавать с нуля одну платежную систему. Я тогда ничего толком не понимал в вопросах бухгалтерии, в том как именно лучше хранить платежи и балансы. Но было подозрение, что примитивный вариант с одной циферкой баланса в аккаунте пользователя слишком прост чтобы быть правильным.

Разобраться и избежать кучи граблей в этом деле мне помогла данная статья. При этом информации по теме "как сделать свою платежную систему" довольно мало, а в учебниках по бухучету программисту сходу разобраться не так просто (и очень нудно). Надеюсь, этот материал окажется полезным тем, кто только собирается что-то такое делать.

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

Введение

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

Двойная бухгалтерская запись в реляционной БД - 1
Лука Пачоли, автор самой старой (15 век) дошедшей до нас книги с описанием принципов двойной записи

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

Основные правила таковы:

Читать полностью »

Бойтесь операций, buffers приносящих…
На примере небольшого запроса рассмотрим некоторые универсальные подходы к оптимизации запросов на PostgreSQL. Пользоваться ими или нет — выбирать вам, но знать о них стоит.
Читать полностью »

Привет! Как водится, три раза в году мы рассказываем о том, над чем работали. Это статья о том, что нового в DataGrip 2019.3, а значит и во всех IDE от JetBrains с поддержкой баз данных.

DataGrip 2019.3: MongoDB, дебаггер, модный прогресс-бар, много новых инспекций - 1
Читать полностью »

image
Фото: www.rbc.ru

Центральный банк РФ будет отслеживать сомнительные операции с помощью анализа мобильных устройств и компьютеров юридических лиц. Для этого ЦБ создал проект межбанковской базы данных с информацией о технике пользователей — «Сервис анализа технических устройств». Мера должна помочь бороться с отмыванием доходов, считает Банк России.
Читать полностью »

Всем привет!

Меня зовут Михаил Мазеин, я — ментор Backend community ManyChat. 5 декабря в нашем офисе пройдёт первый Backend Meetup.

В этот раз мы поговорим не только про разработку на PHP, но и затронем тему использования баз данных.

Начнём с истории про выбор инструментов для вычисления математических формул. Продолжим фундаментальной темой выбора подходящей базы данных. А закончим встречу большим докладом о тюнинге сервера высоконагруженного проекта с помощью тонкой конфигурации nginx и php-fpm на основе данных о движениях запросов вместо постоянного увеличения количества серверов.

5 декабря, ManyChat Backend MeetUp - 1

Участников ждут доклады от инженеров ManyChat и, конечно, общение. Встречать гостей будем в 18:30, а начнем митап в 19:00. Регистрация доступна по ссылке, а подробная программа мероприятия — под катом.
Читать полностью »

Классический вопрос, с которым разработчик приходит к своему DBA или владелец бизнеса — к консультанту по PostgreSQL, почти всегда звучит одинаково: «Почему запросы выполняются на базе так долго?»

Традиционный набор причин:

  • неэффективный алгоритм
    когда вы решили сделать JOIN нескольких CTE по паре десятков тысяч записей
  • неактуальная статистика
    если фактическое распределение данных в таблице уже сильно отличается от собранной ANALYZE'ом в последний раз
  • «затык» по ресурсам
    и уже не хватает выделенных вычислительных мощностей CPU, постоянно прокачиваются гигабайты памяти или диск не успевает за всеми «хотелками» БД
  • блокировки от конкурирующих процессов

И если блокировки достаточно сложны в поимке и анализе, то для всего остального нам достаточно плана запроса, который можно получить с помощью оператора EXPLAIN (лучше, конечно, сразу EXPLAIN (ANALYZE, BUFFERS) ...) или модуля auto_explain.

Но, как сказано в той же документации,

«Понимание плана — это искусство, и чтобы овладеть им, нужен определённый опыт, …»

Но можно обойтись и без него, если воспользоваться подходящим инструментом!
Читать полностью »

image

Небольшая заметка о встраиваемой key-value БД под названием Coffer, написанной на Golang. Если совсем коротко: в остановленном состоянии БД данные лежат на диске, при запуске данные копируются в память. Чтение происходит из памяти. При записи изменяются данные памяти, а изменения записываются в журнал на диск. Максимальный размер хранимых данных ограничен размером оперативной памяти. API позволяет создавать хидеры для записей БД и применять их в транзакциях, сохраняя при этом консистентность данных.
Читать полностью »

«Покрывающий индекс» не просто еще одна фича, которая может пригодиться. Это вещь сугубо практичная. Без них Index Only Scan может не дать выигрыша. Хотя и покрывающий индекс в разных ситуациях эффективен по-разному.

Речь здесь будет не совсем о покрывающих индексах: строго говоря, в Postgres появились так называемые инклюзивные индексы. Но, по-порядку: покрывающий индекс — это индекс, который содержит все значения столбцов, необходимые запросу; при этом обращение к самой таблице уже не требуется. Почти. О «почти» и других нюансах можно прочитать в статье Егора Рогова, входящей в его индексный сериал из 10 (!) частей. А инклюзивный индекс создается специально для поиска по типичным запросам: к поисковому индексу добавляются значения полей, по которым искать нельзя, они нужны только для того, чтобы не обращаться лишний раз к таблице. Такие индексы формируются с ключевым словом INCLUDE.

Анастасия Лубенникова (Postgres Professional) доработала метод btree так, чтобы в индекс можно было включать дополнительные столбцы. Этот патч вошел в версию PostgreSQL 11. Но патчи для методов доступа GiST/SP-GiST не успели созреть до выхода этой версии. К 12-й GiST дозрел.
Читать полностью »

Описание общей потребности в поиске данных и объектов в базе данных

Поиск данных, а также хранимых процедур, таблиц и других объектов в базе данных является достаточно актуальным вопросом в том числе и для C#-разработчиков, а также и для .NET-разработки в целом.

Достаточно часто может возникнуть ситуация, при которой нужно найти:

  1. объект базы данных (таблицу, представление, хранимую процедуру, функцию и т д)
  2. данные (значение и в какой таблице располагается)
  3. фрагмент кода в определениях объектов базы данных

Существует множество готовых решений как платных, так и бесплатных.
Сначала рассмотрим как можно осуществлять поиск данных и объектов в базе данных с помощью встроенных средств самой СУБД, а затем рассмотрим как это сделать с помощью бесплатной утилиты dbForge Search.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js