mysql_real_escape_string / Говнокод #28161 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
-- Теперь мы можем легко получить отчёт по продажам на прошлую дату:

DELIMITER ;
BEGIN;
CALL set_prot_snapshot_date('2018-10-09 17:23:47', NULL, -1);
SELECT NOW() report_time, d.date, SUM(p.amount * p.price) sum
FROM docs d
INNER JOIN doc_pos p ON d.id = p.doc_id
GROUP BY d.date;
ROLLBACK;

https://habr.com/ru/post/425769/
Как научить MySQL заглядывать в прошлое

Запостил: ISO ISO, (Updated )

Комментарии (26) RSS

  • Иногда мне кажется, что дерьмовые технологии каким-то странным образом выворачивают мозги своих пользователей так, чтобы последние не просто делали дерьмо, но и активно его распространяли.
    Ответить
    • зачем вообще для версионирования субд?
      Ответить
      • > для версионирования субд
        для субд версионирование
        (и это не оно)
        Ответить
      • Протоколировать изменения записей в таблицах. Такой себе дерьмоWAL.
        Ответить
        • Почему СУБД из коробки не может хранить старые версии? Там же MVCC, кажется сам бог велел?
          Ответить
          • MVCC — далеко не единственный способ изоляции, он есть не во всех СУБД.

            Показывать же кишки MVCC наружу — плохая идея, потому что в первую очередь оно нужно для обеспечения транзакционности, и если мы дадим к нему доступ — нам придётся обеспечивать изоляцию самих записей MVCC, от чего нам резко станет хуёво (нужен будет MVCC для MVCC).
            Ответить
          • А, ну и ещё: старые версии кортежей в MVCC нужно чистить (в постгре для этого есть «VACUUM»), потому что иначе они будут раздувать таблицы, что рушит всю идею ворсионированности.
            Если же их не чистить — будет больно тем, кому ворсированность не нужна.
            Ответить
            • Так почему не сделать как в Git или ZFS? Хочешь -- сделай снепшот, и теки. Не хочешь -- его заколлектят.
              Ответить
              • Даже если так сделать, всё равно появится оверхед как минимум на хранения таймштампов в версиях строк (без этого геморроя им нужны только tid), плюс придётся городить огромное количество кода для предоставления безопасного доступа к этим данным.

                Короче говоря, много ебли с практически нулевым выхлопом. Ворсирование на триггерах — гораздо более удобное и, главное, гибкое (если, конечно, это не тот пиздец, что в посте).
                Ответить
                • Я не вижу проблем с доступом, они же read only, не?

                  Оверхед будет, но он и с триггерами есть же, не?

                  Мне просто не нравится ручное версионирование на уровне бизнес логики.
                  СУБД дает срез данных на момент какого-то коммита транзакции, так это же то самое версионирование и есть, нужно только научиться diff красиво показывать
                  Ответить
                  • > это же то самое версионирование и есть
                    пэхапэшник плиз
                    это параллелизм
                    а параллелизм начинается с локов и уже в это способ придуманный шваброобезьянов достигает охуительных результатов
                    Ответить
  • > Но на шаред хостингах вам естественно никто не даст ставить что хотите
    А пыхомирок не меняется. Вангую, что в 2030 году пыхомакаки по-прежнему будут жаловаться на невозможность поправить блядский PHP.IИI на блядском шаред хостинге
    Ответить
  • Именно поэтому hysterical data в Yahoo Finance только до 2014, лент у них только на 8 лет.
    Ответить
      • Мудаки в 2022: "текст из четырех предложений -- это сложно, потому инструкцию я лучше оформию в виде видео на утуб"

        Те же мудаки в 2022: (пишут стену ненужного текста про куки который никто никогда не будет читать)


        А откуда ты знаешь про кулэйд? Твое детство прошло в США? Ты может и севен элевн знаешь? И тойзараз? И вальбаумс помнишь? И котеджчиз с бейглом на завтрак ел?
        Ответить

Добавить комментарий

Семь раз отмерь — один отрежь, guest!

    А не использовать ли нам bbcode?


    8