Я говорил о концепте механизма принятия решений. И его несовершенстве.
Что касается обрушения, то, по факту, как раз крупные маркетмейкеры могут проводить массу манипуляций с снижением цены путем распродажи и последующим выкупом по более низкой цене.
Поэтому два семантически разных запроса дадут один и тот же практический результат, но вот затраты с которыми этот результат получен уже разные.
Все правильно. Чаще всего это говорит лишь о том, что исходно использовался не тот запрос что нужен.
Возможно я не смог правильно прочесть это в статье в рамках расставленных акцентов.
в случае с курсами валют здравым смыслом (ну не может быть два разных курса у одной валюты в одном промежутке времени)
Зависит от величины промежутка времени. Даже официальные курсы центральных банков, которые устанавливаются на один день имели преценденты изменяться в течении этого самого дня.
3 строка - это вызов нескольких запросов внутри цикла.
И, да, это можно и нужно свести к join и предвычислениям. Даже если засунуть в один запрос будет слишком сложно, то уж ограничиться до десятка запросов - можно.
если есть bonuses.active.first, то возможен и bonuses.active.last? Будет то же самое поведение или другое? При такой записи точно ответить нельзя
Но, вот влепить два семантически разных запроса и считать их эквивалентными его не смущает....
SELECT "bonuses".* FROM "bonuses" WHERE "bonuses"."user_id" = 123 AND "bonuses"."status" = 'active' LIMIT 1;
Это означает - возьми первый попавшийся. И строго говоря в зависимости от БД и систем даже последовательных два таких запроса могут дать разный результат на одном и том же наборе данных.
SELECT "bonuses".* FROM "bonuses" WHERE "bonuses"."user_id" = 123 AND "bonuses"."status" = 'active' ORDER BY "bonuses"."id" ASC LIMIT 1;
Означает возьми первый по порядку (скорее всего добавления). И вот он будет всегда одинаков на одном и том же наборе данных.
Что касается вашей таблицы курсов...
Rows Removed by Filter: 6340297
То что-то у вас пошло не так. Посмотрите то же партиционирование. Оно должно дать существенный прирост скорости получения данных без нарушения семантики запроса.
Кстати, посмотрел я те исходники, которые вы писали якобы для тестов.
Там либо абсолютная профанация и неквалифицированность, либо сплошное намеренное передергивание. Вы зачем-то со стороны приложения дернули базу 1002 раза. И сравниваете с единичным вызовом запроса.
Надо ли сказать, что все это можно переписать в гораздо меньшее количество запросов? И получить совсем другие цифры?
да, а потом вы это поле пишите в БД и там тоже идёт проверка NOT NULL, 2 логические операции вместо одной
Если вас так уж заботит производительность.
То обращу внимание, что основной способ решения в наших реалиях это горизонтальное масштабирование.
В этом контексте бекенд даст существенную фору БД.
Поэтому вынос логики валидации из БД — это одна из форм разделения ответственности, которая облегчает масштабировани (да, путем большего объема затрат железа и человеческого труда)
Встречаются случаи когда условия собираются поэтапно
Условный код
$criteria = new Criteria(['x' => 1]);
$criteria2 = new Criteria(['y' => 'bla-bla']);
$newCriteria = $criteria->and($criteria2);
$result = $db->find($newCriteria);
Вот тут у меня есть некоторые гарантии что несоответствующее интерфейсу не влезет. Ну, а сама criteria сериализуется в нужный диалект SQL согласно драйвера.
Как можно воспроизвести подобный подход TypeScript?
Формально различные флаги тоже должны войти в версии схемы данных и да, учитываться.
Но вообще-то это справедливо и для уровня приложения-то :)
При общении с БД код должен будет учитывать отличие схем (например, путем реализации собственных абстракций доступа и маппинга данных в рамках фич)
P.S. если что — я не топлю за использование constraints в рамках БД если они сложнее чем foreign key. Просто вышеуказанные проблемы имеют решение даже для идеи вашего визави.
Религия доставляет мне сложность катить миграцию идеально в то же время, в которое происходит релиз кода, который запрещает так делать или обрабатывает такую ситуацию. Это если забыть про откаты релизов, например. Вплоть тдо того, что у вас может быть какой-нибудь роллинг релиз и два часа у вас половина пользователей создает заказы с емейлом, а половина без, так как у вас идет поэтапный деплой. с какого момента мне выставлять дату ограничения если там через один идут заказы с емейлом и без?
Безотносительно позиции вашего визави и его категоричности относительно БД — данный вопрос решается версией схемы данных.
Т.е. во всех таких случаях вам нужно включить в условие валидации еще и кода который с ней работает.
Соответственно это решает вопросы и а/б тестирования и откатов релизов и т.п.
А какую он несет функцию, которой не существовало ранее?
Какой прогресс и инновации он внес?
Меньше чем развивается крипта (люди справлялись за год).
Децентрализация? Пока еще ничего не дала.
А то, что есть это не ее плоды. Это просто результат переноса/развития уже существующих инструментов на базу крипты.
Но и большинство этих инструментов пока что (а может и всегда так будет) лучше работают вне крипты просто будучи перенесены на цифровую платформу.
Вы только что закопали всю крипту пачкой.
Не то чтобы я с вами не согласен. Но в этом контексте непонятна ваша позиция. Вы тоже считаете что текущая крипта это мусор?
Не совсем понимаю причём тут обрушение.
Я говорил о концепте механизма принятия решений. И его несовершенстве.
Что касается обрушения, то, по факту, как раз крупные маркетмейкеры могут проводить массу манипуляций с снижением цены путем распродажи и последующим выкупом по более низкой цене.
Крипта в этом контексте не выделяется.
Странная сентенция, учитывая что саму крипту Китай не запретил. Хотя для лучшего контроля как раз стоило бы запретить её.
Ну, а про электроэнергию вообще лютый бред написали. От увеличения её производства энергоэффективность майнинга не увеличится.
PoS - это эмуляция конструкта "кто
силенбогат тот и прав". Он несколько менее совершенен в сравнении с общественным договором и государствомhttps://3dnews.ru/1001571
Вот есть немного на примере интел.
Якобы -40% в количестве продукции при том же или большем объёме используемых пластин.
На самом деле нет.
Фактически большая часть современных решений на блокчейне это пена неэффективности.
Их существование возможно в узкой нише пока экономика +/- здорова.
В крипту, например, канализируют излишнюю ликвидность финансовых систем.
Как по мне, роль отхожей ямы не тянет на инновации и революцию
Все там понятно. Криптовалюты на текущий момент в общественном восприятии нечто неспокойное, фронтирное, и небезопасное.
И именно эти характеристики влияют на объём интереса у женщин и мужчин по-разному.
Все правильно. Чаще всего это говорит лишь о том, что исходно использовался не тот запрос что нужен.
Возможно я не смог правильно прочесть это в статье в рамках расставленных акцентов.
Зависит от величины промежутка времени. Даже официальные курсы центральных банков, которые устанавливаются на один день имели преценденты изменяться в течении этого самого дня.
get_app_list.php
3 строка - это вызов нескольких запросов внутри цикла.
И, да, это можно и нужно свести к join и предвычислениям. Даже если засунуть в один запрос будет слишком сложно, то уж ограничиться до десятка запросов - можно.
У вас же тот код выполняет 1000+ запросов к БД.
Т.е автора смущает
Но, вот влепить два семантически разных запроса и считать их эквивалентными его не смущает....
Это означает - возьми первый попавшийся. И строго говоря в зависимости от БД и систем даже последовательных два таких запроса могут дать разный результат на одном и том же наборе данных.
Означает возьми первый по порядку (скорее всего добавления). И вот он будет всегда одинаков на одном и том же наборе данных.
Что касается вашей таблицы курсов...
То что-то у вас пошло не так. Посмотрите то же партиционирование. Оно должно дать существенный прирост скорости получения данных без нарушения семантики запроса.
Там, где в цикле выполняются запросы.
Кстати, посмотрел я те исходники, которые вы писали якобы для тестов.
Там либо абсолютная профанация и неквалифицированность, либо сплошное намеренное передергивание. Вы зачем-то со стороны приложения дернули базу 1002 раза. И сравниваете с единичным вызовом запроса.
Надо ли сказать, что все это можно переписать в гораздо меньшее количество запросов? И получить совсем другие цифры?
Я не совсем понимаю почему вы решили, что ваши фантазии имеют хоть какое-то отношение к реальности.
Если вас так уж заботит производительность.
То обращу внимание, что основной способ решения в наших реалиях это горизонтальное масштабирование.
В этом контексте бекенд даст существенную фору БД.
Поэтому вынос логики валидации из БД — это одна из форм разделения ответственности, которая облегчает масштабировани (да, путем большего объема затрат железа и человеческого труда)
Условный код
Вот тут у меня есть некоторые гарантии что несоответствующее интерфейсу не влезет. Ну, а сама criteria сериализуется в нужный диалект SQL согласно драйвера.
Как можно воспроизвести подобный подход TypeScript?
Но вообще-то это справедливо и для уровня приложения-то :)
При общении с БД код должен будет учитывать отличие схем (например, путем реализации собственных абстракций доступа и маппинга данных в рамках фич)
P.S. если что — я не топлю за использование constraints в рамках БД если они сложнее чем foreign key. Просто вышеуказанные проблемы имеют решение даже для идеи вашего визави.
Безотносительно позиции вашего визави и его категоричности относительно БД — данный вопрос решается версией схемы данных.
Т.е. во всех таких случаях вам нужно включить в условие валидации еще и кода который с ней работает.
Соответственно это решает вопросы и а/б тестирования и откатов релизов и т.п.
Рекомендую погуглить про польскую и обратную польскую нотации.
Они реально удобны для конечных автоматов. Поэтому их часто используют в различных query builder
А существуют практические области, где хаскель это единственный подходящий инструмент? О_о