Собственно я имею в виду, что связывание двух копий таблицы, полученной подзапросом (конечно, его нужно преобразовать в CTE), будет более очевидным (и скорее всего менее нагрузочным), чем использование оконных функций. Хорошо, что у вас ну совсем мало корзин, всего 8 штук, о производительности можно сильно не думать.
И совсем мне непонятно, почему вместо получения сразу требуемого результата вы генерируете WHERE clause для другого запроса, который нужно будет выполнять отдельно.
Мне только непонятно, зачем мучаться с проблемой границ, которые приблизительные и могут пропустить записи. Что собственно мешает подвинуть нижнюю границу первой корзины в 1, верхнюю последней в MAXVALUE, а на стыках между корзинами значение на таковое из соседней записи? Тогда достаточно запрашивать только, скажем, MAX(), потом FULL JOIN двух копий (t1.bkt=t2.bkt-1) и COALESCE(). На перекос это почти не повлияет.
Вывод: Если мы положим на склад 11 штук, то с вероятностью 97,5% мы пройдем год без проблем с нехваткой оборудования.
Вы учитываете только смерть оборудования по "внутренним" причинам. А зря. Скачки электропитания, выгорание портов от внешних импульсов/наводок (а хоть бы и молния) или неправильного подключения (вам никогда 220 на порт не прилетало? везучий...), да элементарно физическое повреждение контактов разъёма "кривым" патч-кордом. Так что процентик-то надо бы понизить... хотя я понятия не имею, как правильно учесть риски, подобные перечисленным, и посчитать реальный процент. На практике же пять свичей сверх мат.ожидания, скорее всего, хватит.
"Очередной бред на ваш смартфон!"... вот спасибо! Как же я без этого дерьма раньше-то жил?
Лучше бы интеллект подтянули этому вашему ... интеллекту. А то порой так доставляет! особенно понравилось в Я.Навигаторе - сообщение "Пробка 12 минут (2 км)", и сразу следом "Не упусти свой шанс!". Ни в жисть не поверю, что случайно - он хоть и искусственный, а всё же где-то интеллект. Хотя поговаривают, что ИИ - это "имитация интеллекта".
ограничение не проходит, когда на выходе строго False
Вот и я о том же. Просто обычно как-то оперируют положительной логикой. "Если - то" даёт линейный ответ без дополнительной обработки. А когда начинается "если не - то", сразу начинаются затруднения, потому что надо рассматривать квадрат результат-действие.
Значение null (или unknown) в check constraint просто исключаются из проверки.
Признаться, этой фразы не понял вообще.
На входе имеем запись, которую нужно проверить на соответствие условию.
На первом этапе безусловно вычисляется выражение ограничения. Только после этого этапа мы получаем значение для анализа, которое может быть в т.ч. и NULL. Следовательно, этот этап отпадает, фраза не о нём.
Далее выполняется блок, где на входе - значение проверяемого выражения, а на выходе - решение, соответствует ли запись ограничению либо нет. Вход - один (значение), выходов - два (соответствует либо не соответствует). И вашему "исключаются из проверки" как третьему пути течения процесса в этой схеме просто нет места.
А далее - далее просто ничего нет, вычисления выполнены, решения приняты, работа завершена. Так что в этом месте вашей фразе, пардон за тавтологию, уже не место.
А вот это хоть и вроде бы верное утверждение, но на самом деле очень опасное заблуждение. Никогда не мыслите по шаблону - можете домыслиться до очень неприятных вещей. Например, в CHECK constraint полученное значение NULL интерпретируется как TRUE.
Да элементарно. Если у товарища нет ни одного платежа, то нет ни одной записи с платежом, при LEFT JOIN в поле t.status (и остальных полях от таблицы платежей) будет сгенерировано значение NULL, условие t.status = 'paid' даст NULL, который интерпретируется как FALSE, и запись для этого товарища не попадёт в выходной набор.
Вот корректный подход — фильтровать оплаченные транзакции прямо в ON, чтобы не потерять клиентов без оплат
Не менее корректный подход - INNER JOIN + UNION. И он может оказаться даже более эффективным - впрочем, всё зависит от схемы и статистики данных. А ещё - сразу снимаются первые два дополнительных вопроса.
Решение чаще всего строят через ранжирование записей и накопление значений окна
За такое решение надо ставить жирный минус. Считать сумму 3 записей по всему массиву - это ж надо было придумать... всё агрегирование во внешнем запросе, а в CTE только нумерация.
WITH ranked AS (
SELECT
client_id,
trx_date,
amount,
ROW_NUMBER() OVER (PARTITION BY client_id ORDER BY trx_date DESC) AS rn,
FROM transactions
)
SELECT client_id,
MAX(trx_date) AS last_trx_date,
SUM(amount) AS sum_last3_trx
FROM ranked
WHERE rn < 4
GROUP BY client_id;
И я бы ещё затребовал пометку, у кого меньше трёх записей.
Во-первых, оказывается, "Поздравляю вас, гражданин, соврамши!" (с). Это ни разу не бесплатный сервис. Это просто рекламная акция, на время которой предоставляется такой сервис в форме, не требующей оплаты. Ну и как же без "Пользователь вправе использовать BI.ZONE Public DNS исключительно для некоммерческих целей в соответствии с положениями Соглашения. Иное использование BI.ZONE Public DNS недопустимо." - так вот в пользовательском соглашении и написано.
Во-вторых, бесплатность - она только на время акции. Которое "Срок проведения — с 01.12.2025 до момента размещения уведомления о прекращении Акции на официальном сайте Организатора." То есть когда цели акции будут достигнуты (почитайте, кстати, каковы они) - бесплатность, скорее всего, кончится. Что имхо подтверждает фраза "В период проведения Акции Организатор предоставляет Участникам возможность настройки и использования BI.ZONE Public DNS на безвозмездной основе."
А заодно - вам никто не сообщит, что акция закончилась. Сами находите и читайте. Ничего не напоминает?
В ноябре 2025 года представлен новый режим Windows под названием Digital Signage Mode («Режим цифрового табло»), который гасит BSoD через 15 секунд. Так что синий экран (который теперь чёрный) перестанет быть частью городского ландшафта.
Ну да ну да... появился новый режим, и все вот прям бросятся заменять искпишки да семёрки (а кое-где до сих пор и 95-я есть) на управляющих выводом компах на свежую 11-ю с такой жизненно важной фичей... Вы их что, совсем за дураков считаете?
Ну не надо путать причину и следствие. Приведённые вами эмпирические зависимости - это следствие тех законов, который вы почему-то считаете всего лишь обоснованием.
Классическая эмпирическая рекомендация "shared_buffers = 25% от объёма оперативной памяти" не подтверждается строгим экспериментом и может считаться научно необоснованной.
??? o_O
А вы что, можете привести пример эмпирической рекомендации, которая обоснована научно? Эти термины вообще взаимоисключающи - либо эдак, либо так, но ни в коем случае не одновременно.
Если слово есть в трёх словарях, но отсутствует в четвёртом, то условие "нет хотя бы в одном" выполнено, и слово является иностранным. Ваша же интерпретация "слово не является иностранным, если есть хотя бы в одном из словарей" с изложенными в статье правилами и фактами никак не соотносится.
Хотя я вполне допускаю, что это именно автор написал туфту. Но в данном конкретном случае обсуждается именно текст статьи, изложенные в ней факты, а не реальное состояние дел.
Первое, о чем я подумал, когда их увидел — «А как эту проверку автоматизировать?». Ну, чтобы взять сайт, прогнать его через какую-то систему, и понять, какие слова теперь считаются иностранными.
Иными словами, НЕ иностранными являются слова, которые присутствуют во всех четырёх словарях. Поверьте, обработка четырёх словарей, выборка слов, присутствующих во всех четырёх словарях, и получение на выходе "исчерпывающего перечня НЕиностранных" слов - это пара минут. Вы дольше будете эти словари скачивать и готовить к импорту. Кстати, кто-нибудь это обязательно проделает - так что непременно будет доступен уже готовый к употреблению датасет. А потом взять текст, разбить на токены (слова), нормализовать (падежи там и прочие навороты), отбросить всякие предлоги-междометия, а остаток сверить с полученным словарём - это, грубо говоря, секунда на мегабайт анализируемого очищенного (плоского) текста, даже просто на более-менее не убитой машине.
Пробовал с разными нейросетями — не получилось. В обычном пользовательском режиме они не справляются. Объем словарей слишком большой.
Не надо пробовать с нейросетями. Тут нужен простейший алгоритм, тупой и прямой, как лом.
PS. Кстати, в том списке из 4 словарей один называется "Словарь иностранных слов". И как-то совершенно неясно - слова в нём русскоязычные и разрешены, или наоборот, иностранные и запрещены?
Так они б/у и сейчас вовсе незаоблачно продаются.
Собственно я имею в виду, что связывание двух копий таблицы, полученной подзапросом (конечно, его нужно преобразовать в CTE), будет более очевидным (и скорее всего менее нагрузочным), чем использование оконных функций. Хорошо, что у вас ну совсем мало корзин, всего 8 штук, о производительности можно сильно не думать.
И совсем мне непонятно, почему вместо получения сразу требуемого результата вы генерируете WHERE clause для другого запроса, который нужно будет выполнять отдельно.
Мне только непонятно, зачем мучаться с проблемой границ, которые приблизительные и могут пропустить записи. Что собственно мешает подвинуть нижнюю границу первой корзины в 1, верхнюю последней в MAXVALUE, а на стыках между корзинами значение на таковое из соседней записи? Тогда достаточно запрашивать только, скажем, MAX(), потом FULL JOIN двух копий (t1.bkt=t2.bkt-1) и COALESCE(). На перекос это почти не повлияет.
Упс... чёта как-то я его проглядел. Ну да...
Вы учитываете только смерть оборудования по "внутренним" причинам. А зря. Скачки электропитания, выгорание портов от внешних импульсов/наводок (а хоть бы и молния) или неправильного подключения (вам никогда 220 на порт не прилетало? везучий...), да элементарно физическое повреждение контактов разъёма "кривым" патч-кордом. Так что процентик-то надо бы понизить... хотя я понятия не имею, как правильно учесть риски, подобные перечисленным, и посчитать реальный процент. На практике же пять свичей сверх мат.ожидания, скорее всего, хватит.
"Очередной бред на ваш смартфон!"... вот спасибо! Как же я без этого дерьма раньше-то жил?
Лучше бы интеллект подтянули этому вашему ... интеллекту. А то порой так доставляет! особенно понравилось в Я.Навигаторе - сообщение "Пробка 12 минут (2 км)", и сразу следом "Не упусти свой шанс!". Ни в жисть не поверю, что случайно - он хоть и искусственный, а всё же где-то интеллект. Хотя поговаривают, что ИИ - это "имитация интеллекта".
... Не, а чо я-то? я сама охренела... (с)
Вот и я о том же. Просто обычно как-то оперируют положительной логикой. "Если - то" даёт линейный ответ без дополнительной обработки. А когда начинается "если не - то", сразу начинаются затруднения, потому что надо рассматривать квадрат результат-действие.
Признаться, этой фразы не понял вообще.
На входе имеем запись, которую нужно проверить на соответствие условию.
На первом этапе безусловно вычисляется выражение ограничения. Только после этого этапа мы получаем значение для анализа, которое может быть в т.ч. и NULL. Следовательно, этот этап отпадает, фраза не о нём.
Далее выполняется блок, где на входе - значение проверяемого выражения, а на выходе - решение, соответствует ли запись ограничению либо нет. Вход - один (значение), выходов - два (соответствует либо не соответствует). И вашему "исключаются из проверки" как третьему пути течения процесса в этой схеме просто нет места.
А далее - далее просто ничего нет, вычисления выполнены, решения приняты, работа завершена. Так что в этом месте вашей фразе, пардон за тавтологию, уже не место.
Так что же вы на самом деле хотели сказать?
А вот это хоть и вроде бы верное утверждение, но на самом деле очень опасное заблуждение. Никогда не мыслите по шаблону - можете домыслиться до очень неприятных вещей. Например, в CHECK constraint полученное значение NULL интерпретируется как TRUE.
Да элементарно. Если у товарища нет ни одного платежа, то нет ни одной записи с платежом, при LEFT JOIN в поле t.status (и остальных полях от таблицы платежей) будет сгенерировано значение NULL, условие t.status = 'paid' даст NULL, который интерпретируется как FALSE, и запись для этого товарища не попадёт в выходной набор.
Выход патча из строя, утрата им работоспособности - это, увы, реалии. И глубоко плевать, есть ли у него срок годности...
Не менее корректный подход - INNER JOIN + UNION. И он может оказаться даже более эффективным - впрочем, всё зависит от схемы и статистики данных. А ещё - сразу снимаются первые два дополнительных вопроса.
За такое решение надо ставить жирный минус. Считать сумму 3 записей по всему массиву - это ж надо было придумать... всё агрегирование во внешнем запросе, а в CTE только нумерация.
И я бы ещё затребовал пометку, у кого меньше трёх записей.
Ну если поглядеть попристальнее...
Во-первых, оказывается, "Поздравляю вас, гражданин, соврамши!" (с). Это ни разу не бесплатный сервис. Это просто рекламная акция, на время которой предоставляется такой сервис в форме, не требующей оплаты. Ну и как же без "Пользователь вправе использовать BI.ZONE Public DNS исключительно для некоммерческих целей в соответствии с положениями Соглашения. Иное использование BI.ZONE Public DNS недопустимо." - так вот в пользовательском соглашении и написано.
Во-вторых, бесплатность - она только на время акции. Которое "Срок проведения — с 01.12.2025 до момента размещения уведомления о прекращении Акции на официальном сайте Организатора." То есть когда цели акции будут достигнуты (почитайте, кстати, каковы они) - бесплатность, скорее всего, кончится. Что имхо подтверждает фраза "В период проведения Акции Организатор предоставляет Участникам возможность настройки и использования BI.ZONE Public DNS на безвозмездной основе."
А заодно - вам никто не сообщит, что акция закончилась. Сами находите и читайте. Ничего не напоминает?
Ну да ну да... появился новый режим, и все вот прям бросятся заменять искпишки да семёрки (а кое-где до сих пор и 95-я есть) на управляющих выводом компах на свежую 11-ю с такой жизненно важной фичей... Вы их что, совсем за дураков считаете?
Ну не надо путать причину и следствие. Приведённые вами эмпирические зависимости - это следствие тех законов, который вы почему-то считаете всего лишь обоснованием.
??? o_O
А вы что, можете привести пример эмпирической рекомендации, которая обоснована научно? Эти термины вообще взаимоисключающи - либо эдак, либо так, но ни в коем случае не одновременно.
Что??? Вы то ли не читали ни статьи, ни цитат из неё в моём комментарии, то ли с логикой не дружите. Автор совершенно чётко пишет:
Если слово есть в трёх словарях, но отсутствует в четвёртом, то условие "нет хотя бы в одном" выполнено, и слово является иностранным. Ваша же интерпретация "слово не является иностранным, если есть хотя бы в одном из словарей" с изложенными в статье правилами и фактами никак не соотносится.
Хотя я вполне допускаю, что это именно автор написал туфту. Но в данном конкретном случае обсуждается именно текст статьи, изложенные в ней факты, а не реальное состояние дел.
FAQ -> ЧаВо (Частые Вопросы). Используется ну очень давно...
Да ладно, тривиальная же ж задачка.
Иными словами, НЕ иностранными являются слова, которые присутствуют во всех четырёх словарях. Поверьте, обработка четырёх словарей, выборка слов, присутствующих во всех четырёх словарях, и получение на выходе "исчерпывающего перечня НЕиностранных" слов - это пара минут. Вы дольше будете эти словари скачивать и готовить к импорту. Кстати, кто-нибудь это обязательно проделает - так что непременно будет доступен уже готовый к употреблению датасет. А потом взять текст, разбить на токены (слова), нормализовать (падежи там и прочие навороты), отбросить всякие предлоги-междометия, а остаток сверить с полученным словарём - это, грубо говоря, секунда на мегабайт анализируемого очищенного (плоского) текста, даже просто на более-менее не убитой машине.
Не надо пробовать с нейросетями. Тут нужен простейший алгоритм, тупой и прямой, как лом.
PS. Кстати, в том списке из 4 словарей один называется "Словарь иностранных слов". И как-то совершенно неясно - слова в нём русскоязычные и разрешены, или наоборот, иностранные и запрещены?