Исследование основано на элементарном анкетировании. А где, собсно, обоснование, что лошадь поставлена впереди телеги, а не наоборот? Где доказательство, что именно потребление чая/кофе влияет на минерализацию костей? Может, на практике-то всё с точностью до наоборот, и это уровень минерализации влияет на пищевые предпочтения, что и выражается в т.ч. в смещении соотношения потребления чая/кофе.
Ну и ничего не сказано про верификацию результатов анкетирования. А то все ж помнят, что в Виллариба средняя длина 29 сантиметров, а в Виллабаджо только 13...
Собственно я имею в виду, что связывание двух копий таблицы, полученной подзапросом (конечно, его нужно преобразовать в 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
А вы что, можете привести пример эмпирической рекомендации, которая обоснована научно? Эти термины вообще взаимоисключающи - либо эдак, либо так, но ни в коем случае не одновременно.
Если слово есть в трёх словарях, но отсутствует в четвёртом, то условие "нет хотя бы в одном" выполнено, и слово является иностранным. Ваша же интерпретация "слово не является иностранным, если есть хотя бы в одном из словарей" с изложенными в статье правилами и фактами никак не соотносится.
Хотя я вполне допускаю, что это именно автор написал туфту. Но в данном конкретном случае обсуждается именно текст статьи, изложенные в ней факты, а не реальное состояние дел.
Вот нравятся мне такие "исследования".
Исследование основано на элементарном анкетировании. А где, собсно, обоснование, что лошадь поставлена впереди телеги, а не наоборот? Где доказательство, что именно потребление чая/кофе влияет на минерализацию костей? Может, на практике-то всё с точностью до наоборот, и это уровень минерализации влияет на пищевые предпочтения, что и выражается в т.ч. в смещении соотношения потребления чая/кофе.
Ну и ничего не сказано про верификацию результатов анкетирования. А то все ж помнят, что в Виллариба средняя длина 29 сантиметров, а в Виллабаджо только 13...
Так они б/у и сейчас вовсе незаоблачно продаются.
Собственно я имею в виду, что связывание двух копий таблицы, полученной подзапросом (конечно, его нужно преобразовать в 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 -> ЧаВо (Частые Вопросы). Используется ну очень давно...