Slava Rozhnev

Биржа в качестве гаранта, как еще один из вариантов

fetchone

Переведите это и поймёте. Ну и прочитайте базовую инструкцию по использованию вашей базы.

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

На английском есть специализированный сайт codereview@stackexchange, при наличии языка это идеальный вариант.

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

Самый надёжный способ получить code-review, это завести два аккаунта. С одного задать вопрос, "как сделать то-то", а с другого - запостить код, который это делает. И тут же набегут советчики, рассказать, что в этом коде неправильно.

Как-то так:

CREATE FUNCTION textDecrypt (input TEXT)
RETURNS TEXT DETERMINISTIC
BEGIN
  DECLARE crypt_str BLOB;
  DECLARE key_str BINARY(32);
  DECLARE init_vector BINARY(16);
  SET crypt_str = FROM_BASE64(input);
  SET key_str = UNHEX(SHA2('marks', 256));
  SET init_vector = REPEAT('\0', 16);
  SET block_encryption_mode = 'aes-256-cbc';
  RETURN AES_DECRYPT(crypt_str, key_str, init_vector);
END

https://sqlize.online/sql/mysql80/6fde6e8b7a619316...

PHP здесь вообще не нужен, мysql прекрасно умеет работать с датами сама.

r.date_added > curdate() - interval 30 day

И на будущее, никогда не использовать date() в условии.

У вас очень логичный вопрос на счет сеттера: сеттер полностью уничтожает задумку с инкапсуляцией. Правильно это называется "семантическое нарушение инкапсуляции" — то есть как-бы мы инкапсулировали, но по факту назад открыли прямую запись в свойство напрямую. Все доводы "ну мы можем в сеттере валидировать" не корректны

Правильным способом будет не использовать сеттеры. Вот моя статья на эту тему:
https://habr.com/ru/post/469323/

Более подробно: каждый класс нужно проектирвовать так, чтобы данные внутри были максимально связаны. Например каждый метод работать должен в хорошем случае с максимальным числом полей класса, тогда у него высокий cohesion... В тоже время снаружи наужно работать с максимальн омалым числом метода, тогда будет низкая связанность (coupling). Это пара принципов из GRASP.
Когда вы делаете сеттеры и геттеры, то у вас данные внутри между собой почти никак не взаимодействут: с геттером работают снаружи, с сеттером работаю снаружи — весь класс нараспашку, а в нем в 100% случаев появляются данные, которые вместе не должны находиться и никак не связаны — анрушена и абстракция и инвариант и много чего еще...

Про инвариант отдельно: например есть платеж, у него есть значение, с которым платеж инициирвоан (initValue), есть значение холда (holdAmount) и есть значение чарджа на списание (chargeAmount)
Когда вы работаете с платежом, контролируя ивнариант в самом классе, то ваш каждый метод првоеряет др значения и позволяет перейти к др состоянию... методов будет 2-3, все инкапсулировано и безопасно.

Например:

class Payment {
     pub func charge(amount int) void {
          if (this.holdAmount < amount && this.initAmount < amount) {
               throw new PaymentException('Unavailable charge amount')
          }

           if (this.status === PaymentStatus:finish) {
               throw new PaymentException('Payment already fisnished')
          }

          this.chargeAmount = amount
          this.holdAmount -= amount
          this.status = PaymentStatus:finish
     }
}

Тут в одном методе полные проверки и класс сам контролирует все состояние внутри, также соблюдается закон Деметры. У даннго кода высокий cohesion (из GRASP), тк внутри идет плотная работа с внутр данными (значит они корректно тут закроекны) и низкий coupling ( с теми данными для данного кейса только один метод работы, все внутри)

Когда вы раскроете сеттерами и геттерами, то ваше состояние становится непредсказуемо и полагается только на то, что снаружи точно подумали об инварианте (нет)

Да, нужно делать реорганизацию - операция потенциально требует переноса данных между партициями.

Прмер:

CREATE TABLE table_name (create_date DATE);

ALTER TABLE table_name 
PARTITION BY RANGE(create_date + 0) (
    PARTITION p_old VALUES LESS THAN(20111201),
    PARTITION p_1 VALUES LESS THAN(20120201),
    PARTITION p_2 VALUES LESS THAN(MAXVALUE)
);

Добавляем партицию (точнее, разделяем партицию на две):

ALTER TABLE table_name
    REORGANIZE PARTITION p_2 INTO (
        PARTITION p_2 VALUES LESS THAN (20130101),
        PARTITION p_max VALUES LESS THAN (MAXVALUE)
);

DEMO

SELECT *, AVG(RT) OVER (PARTITION BY Curr, YEAR(Dates) ORDER BY Dates) AS example
FROM src_table

Используйте более подробный log_line_prefix. В частности, нужен %h

log_line_prefix = '%m %p %u@%d from %h [vxid:%v txid:%x] [%i] '

Мы такой используем если нет значимых причин для иного.

Спросил у нашего преподавателя, его рекомендации ниже:

Вот интересные книги:
“Database Internals” by Alex Petrov,
“PostgreSQL изнутри" Рогов.

1 книга - работа в общем для баз данных,
2 книга - конкретно PostgreSQL

Select t1.ID, t1.TIME
from 
TABLE_1 t1 
JOIN TABLE_2 t2 ON t1.ID=t2.ID
              and to_char(t1.TIME, 'DD.MM.YYYY HH24') = to_char(t2.TIME, 'DD.MM.YYYY HH24')

Вариант 2 (возможно, пригодится при оптимизации, так как на выходе сравниваются значения в типе дата время, а не строк):

... and trunc(t1.TIME, 'hh24') = trunc(t2.TIME, 'hh24')

PS: Хорошо бы еще индекс создать под этот формат времени для колонок t1.TIME и t2.TIME, тогда запрос будет всегда производителен.