Pull to refresh
-8
0
Вадим @zVadim

Программист C#

Send message

Он пропитал водой и должен быть слишком тяжел для такого применения

Ну почему вес нужно измерять в автомобилях или слонах, а эксперимент демонстрировать в лучших традициях Копперфильда под листом непрозрачного поликарбоната?

Дзенский калиграффический символ Энсо - мы видим в нем круг

И не только. Еще, в нижней части иллюстрации мы видим QR-код.

С одной стороны, такое восприятие полностью согласуется с предшествующим абзацем. Мы видим идею о QR-коде в чем-то, отдаленное напоминающем его. С другой стороны, изучая труды предков и имея современный багаж знаний о природе, нам свойственно заблуждаться. Можно ошибочно предполагать, что все уже было ПРАВИЛЬНО понято давным-давно до нас

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

Различие женских и мужских голов в части приоритетов удобности и красоты - это стереотип. Удобство, нравится всем, и с этим обычно вопросов нет. А с "красотой" все очень сложно. Обычно, под ней подразумевает некую норму в каком-то обществе в какой-то исторический период. Быть "некрасивым" - значит не соответствовать норме (быть ненормальным). Переносимость своей "ненормальности" индивидуальна, и не сильно зависит от пола, но сами нормы у полов разные.

Пример 1. Программер/админ ходит на работу не брит-не чёсан в растянутом свитере - это вариант нормы. Чтобы произвести вау-эффект, ему достаточно побриться и надеть новый свитер. Для девушек же часто эпиляция, маникюр, укладка и макияж - обязательный минимум для соответствия норме.

Пример 2. Гетеросексуальный мужчина в СНГ стоит перед выбором: надеть очень удобное и красивое платье (не призыв и не пропаганда) или очень неудобные и грязные штаны. Несложно предугадать его выбор: мужчина предпочтет "красоту" перед удобством. Это произойдет из-за установки "мужик в платье - ненормально", которая может рационализироваться тысячью способами: от "платье создано для женской фигуры и не подходит мужской" до "западло, пацаны не поймут"

Пример 3. Герою из второго примера меняем ориентацию или место пребывания (например на Таиланд), и вот его выбор будет не так очевиден.

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

можно применить декларативное партицирование, но формально это будет не та же самая таблица, а соседняя. В этом случае точно будет даунтайм при переключении на новую таблицу

В postgresql нельзя преобразовать обычную в секционированную декларативно, но можно подключить обычную в качестве секции. Как вариант, можно создать новую таблицу секционированную by range, подключить в нее существующую, не забыв при этом о наличии ограничений на диапазон значений ключа секционирования в подключаемой таблице. А затем, переименовать обе, таблицы. Сам так не делал, и подозреваю, что это не всегда применимо из-за зависимостей исходной таблицы.

PS: Я долго не мог определиться какой термин использовать "секционирование" или "партицирование". К первому варианту склонился после длительного чтения документации postgresql. Интересно, почему вы выбрали второй вариант? Во избежании холивара, я ваш выбор уважаю, и считаю оба варианта равноправными

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

К сожалению, странный подход с записью агрегатов в ту же таблицу сработал как красная тряпка, и увел фокус внимания от демонстрации возможностей PostgreSQL к вопросам проектирования БД. Моя "неочевидность" про структуру базы, а не про запросы - они предельно понятны. Спасибо за Ваш труд!

Наличие хаба "Ненормальное программирование" снимает все вопросы к статье (сразу не обратил внимание). Знание таких возможностей PostgreSQL безусловно полезно.

Но у такой организации данных в базе могу придумать только два оправдания: демо-пример для статьи или легаси. Вторая таблица может решить проблему "неочевидности" одним своим наименованием)

WITH current_hour as
(
  SELECT *
  FROM 
    metrics
  WHERE -- #1.1: условие отбора певого часа
    ts > ...
)
INSERT INTO metrics AS m(id, ts, temp_val, qty)
  SELECT
    id
  , date_trunc('hour', ts)
  , avg(temp_val)
  , count(*)
  FROM
    current_hour
  WHERE -- #1.2 : условие отбора "первички"
    qty IS NULL AND
  GROUP BY
    1, 2
ON CONFLICT
  (id, ts) WHERE qty IS NOT NULL -- #2 : условие UNIQUE-индекса "агрегатов"
  DO UPDATE SET
    (temp_val, qty) = (EXCLUDED.temp_val, EXCLUDED.qty)
    WHERE -- #3 : условие обновления записи
      (m.temp_val, m.qty) IS DISTINCT FROM (EXCLUDED.temp_val, EXCLUDED.qty);

Вот таким незатейливым образом с использованием CTE можно получить целых 4 WHERE...

Вот только как быть с посылом из начала статьи "..вместо сложной логики..." ? Вместо простого разделения на две таблицы с очевидными SQL-запросами к ним наворотили вот это с первичкой и агрегатами в одной таблице. А что будет если в какой-то час этот скрипт не отработает, отдельный писать для агрегации прошлых интервалов?

Лет в 12 чинил гирлянду. Разложил её на полу. Самостоятельно "изобретя" метод дихотомии, нашел сгоревшую лампочку за несколько измерений тестером. "Вычислил", что при 220В в розетке и 20 лампочках в гирлянде, на каждую приходится по 11В. На последок, перед тем как зашунтировать неисправную лампу, решил побывать на ее месте. Ведь 11В — фигня, чуть больше чем в Кроне. С этой мыслью, решительно взялся двумя руками за проводки. Какого же было моё удивление, что по ощущениям там было "чуть большее" напряжение. Хорошо, что не решился на язык попробовать (а идея такая была).

Information

Rating
Does not participate
Location
Тула, Тульская обл., Россия
Registered
Activity