Юзер жмет кнопку "старт", я кладу запись с отметкой времени и типом, пока видится как оптимальная структура, но не совсем ясно как теперь вычислять удобно результаты

Хотя вот кажется lead/lag должно помочь наверное

Хотя вот не совсем понятно до конца, если у меня есть тип "пауза", исключить такие записи из выборки я не могу, тогда таймлайн разломается, а временные интервалы пауз мне суммировать не надо

Атрибуты бывают разных типов. Для них и нужно.

я видимо чего то не знаю о электронных компонентах

Всем привет. Думаю как сделать трекер времени. Пока сделал таблицу в которой храню отметку времени и тип действия (старт/пауза/стоп/восстановлено с паузы) Как бы оптимально проссумировать затраченое время при этом исключив промежутки пауз?

а причем тут БД?

а причем тут БД?

Предлагаете отправиться чатик по постгресу с этим вопросом?)

Предлагаете отправиться чатик по постгресу с этим вопросом?)

а зачем вообще в этом процессе база данных?

Потому что я не фанат лопатить данные в приложении.

Когда такие вещи можно "спросить" у базы данных, которая и собственно хранит (ближе всего) к этим самым данным

Потому что я не фанат лопатить данные в приложении.

ну тогда я бы предложил подумать как это хранить... и главное зачем

я видимо чего то не знаю о электронных компонентах

Ты про EAV видимо не знаешь/догоняешь. Там это типичная проблема. При чём независимо от предметной области.

Ты про EAV видимо не знаешь/догоняешь. Там это типичная проблема. При чём независимо от предметной области.

я не догоняю нахрена городить огород там где он никуда не упирался

ну тогда я бы предложил подумать как это хранить... и главное зачем

Ну сейчас это хранится построчно — id, timestamp, action

Ну сейчас это хранится построчно — id, timestamp, action

подумай еще

подумай еще

Это типа саркастическая подсказка или серьезный совет?)

представь что ты хранишь сессию. у которой есть начало, конец, продолжительность

Это типа саркастическая подсказка или серьезный совет?)

это тест на идиотизм :)

Хранение просто одной отметки избавляет меня от проблем с вычислением дюрейшена

Что я сильно не хотел бы делать

Хранение просто одной отметки избавляет меня от проблем с вычислением дюрейшена

а ну да. зато потом ты сидишь и такой чешешь репу как же мне это посчитать когда все это свалено как попало. ГЕНИАЛЬНО!

У всего есть свои плюсы и минусы ) Осталось понять насколько велики минусы текущие

Потму что вычисление дюрейшена это дополнительные запросы в базу из приложения, потенциальные баги + потенциальные сбои по секундам в дюрейшене

В кино же тоже снимаю по несколько концовок / вариаций. Вот и я так же ) Хочу понять на сколько "убог" будет вариант с селектингом на уровне базы, потому что минусы с вариантом на уровне приложения чист и понятен

Потму что вычисление дюрейшена это дополнительные запросы в базу из приложения, потенциальные баги + потенциальные сбои по секундам в дюрейшене

и что хочется? хранить в базе но при этом не запрашивать из базы?

Потму что вычисление дюрейшена это дополнительные запросы в базу из приложения, потенциальные баги + потенциальные сбои по секундам в дюрейшене

Я думаю тебе надо разделить БД на две части, одну оперативную, с фиксацией событий, другую историческую, где события будут предобработаны и выложены в удобном для поиска/обработки виде

У меня тут MVP ребят, какие две базы, вы что )

Я думаю тебе надо разделить БД на две части, одну оперативную, с фиксацией событий, другую историческую, где события будут предобработаны и выложены в удобном для поиска/обработки виде

и запрашивать ДВЕ БАЗЫ КАРЛ? ты че

В кино же тоже снимаю по несколько концовок / вариаций. Вот и я так же ) Хочу понять на сколько "убог" будет вариант с селектингом на уровне базы, потому что минусы с вариантом на уровне приложения чист и понятен

Задача поиска в таблице предыдущей/последующей записи от данной плохая для РСУБД. Запросы получаются сложные и медленные.

и запрашивать ДВЕ БАЗЫ КАРЛ? ты че

ЗАпрашивать одну базу. ПОтом, не БАЗУ а ЧАСТЬ БАЗЫ.

У меня тут MVP ребят, какие две базы, вы что )

MVP это что?

У меня тут MVP ребят, какие две базы, вы что )

Две таблицы)

ЗАпрашивать одну базу. ПОтом, не БАЗУ а ЧАСТЬ БАЗЫ.

он и одну то не хочет запрашивать и потом вычислять и апдейтить.. а ты хочешь что бы две

MVP это что?

Minimum viable product

БЛЯТЬЭТОЁБАНЫЙ РКН ПОЛИНТЕРНЕТА ЗАБАНИЛ!

Нихера не найти!

Ну сейчас это хранится построчно — id, timestamp, action

А вообще это event sourcing пахнет)

Minimum viable product

Ну я боюсь каким бы он ни был минимальным, а чтобы был viable (я уже забыл как переводится), то ПРИДЁТСЯ иметь две части в БД и делать последовательную предобработку.

Я же говорю, такие запросы хреново работают.

Я почти дописал этот конский запрос на вычисление, щас скоро вам на суд представлю.

Возможно, у тебя какой-то частный случай и у тебя будет всё ок. ТОгда не ясно с чего ты спрашиваешь

Ну просто малоли я что-то упустил ) Щас посмотрим

Я всегда рад спросить совета )

Где срач, там и истина, сами же знаете.

Я почти дописал этот конский запрос на вычисление, щас скоро вам на суд представлю.

я прям чета под столом уже... то есть ради того что бы не обращатся один раз в базу и расчета в одной строчке и апдейта строки. ты решил нагрузить базу так что бы она аж окосела расчитывая твой еюический запрос?

я прям чета под столом уже... то есть ради того что бы не обращатся один раз в базу и расчета в одной строчке и апдейта строки. ты решил нагрузить базу так что бы она аж окосела расчитывая твой еюический запрос?

Не все запросы которые выглядят как кусок говна работают долго, кстати.

если там кто рядом. то сломайте ему пальцы

я прям чета под столом уже... то есть ради того что бы не обращатся один раз в базу и расчета в одной строчке и апдейта строки. ты решил нагрузить базу так что бы она аж окосела расчитывая твой еюический запрос?

Ладно, Алекс кончай уже тролить человека, он вроде вменяемый.

Не все запросы которые выглядят как кусок говна работают долго, кстати.

Обратное тоже верно.

Чем меньше кода написано тем меньше потенциальных багов, вопрос производительности пока десятый

Обратное тоже верно.

Согласен, везде надо смотреть

Не все запросы которые выглядят как кусок говна работают долго, кстати.

давай я тебе кое что раскажу про работу баз... то что ты пишеш один длинный запрос нихрена не значит что ты обратился в базу один раз... технчиески да. от клиента ушел один запрос. но на практике твой запрос получит интерпретатор и он будет ибическое количество раз запрашивать базу пока не соберет все данные. и потом их считать..

и заместо одного запроса и 1 апдейта. ты получишь полное веселье на стороне базы. и это веселье с ростом клиентов будет расти геометрически

Смотрите, мне на основе времени людям бабки платить, если что-то не так пойдет в PHP (а так всегда бывает, ну вы же все знаете) то проеб по деньгам мне нужен меньше всего на свете

(вместо)

Смотрите, мне на основе времени людям бабки платить, если что-то не так пойдет в PHP (а так всегда бывает, ну вы же все знаете) то проеб по деньгам мне нужен меньше всего на свете

и как это вообще соотносится?

Не знаю даже как донести иначе

ты думаешь что ты в 2018 году изобрел контроль рабочего времени?

Не знаю даже как донести иначе

Ты запрос обещал...

Да как только AI перестанет вопросами заваливать!)

А постгри кэштрует запросы?

А постгри кэштрует запросы?

Там есть генетический оптимизатор

А постгри кэштрует запросы?

В каком смысле?

Ой тут что-то было такое красивое.... НО я не успел рассмотреть

В каком смысле?

Ну умеем запрос, на выборку одной строки, с условием - условие попадает в индекс. И по идее нада бы закэшировать или план выполнения запроса, или сам запрос - точнее сейчас не смогу сказать. Суть в том чтоб не оптимизатор каждый раз мучать, а по кэшу работать. з.ы. почему вопрос возник - давно постгри не смотрел, более с другими БД работал

А постгри кэштрует запросы?

Если в смысле как MySQL, то НЕТ. Он данные кэширует. Кэшировать запросы бессмысленно

ERROR: S client not available

нет имелось ввиду план выполнения запроса поселить в кэш

Ну умеем запрос, на выборку одной строки, с условием - условие попадает в индекс. И по идее нада бы закэшировать или план выполнения запроса, или сам запрос - точнее сейчас не смогу сказать. Суть в том чтоб не оптимизатор каждый раз мучать, а по кэшу работать. з.ы. почему вопрос возник - давно постгри не смотрел, более с другими БД работал

Кэш планов есть кажется в любой СУБД.

Я PG плохо знаю, но думаю, что кэширует

ХОТЯ БЫ для одного соединения.

просто в MySQL кэш планов запросов помоему живет токо пока есть соединение. Я последние пол года просто NoSQL БД мучаю - сейчас тяжко немного - но скроро пройдет

Да, привыкай к хорошему...

просто в MySQL кэш планов запросов помоему живет токо пока есть соединение. Я последние пол года просто NoSQL БД мучаю - сейчас тяжко немного - но скроро пройдет

Про MySQL я тоже не знаю.

Но в принципе кэши планов делают во всех СУБД.

Приветствую А не подскажете, можно ли проверить пустой результат в mysql? то есть что-то вроде IF EXISTS (select a from table) select a from table ELSE select b from table

Ты запрос обещал...

https://gist.github.com/korotovsky/51135a9ededdba50ef4a6d63ab58517f

@AlexCAD ^ ?

Еще раз здравствуйте) ни у кого случайно нет дико тюнингованного конфига для Single Node кассандры ?) (Можно шутить про "в гугле забанили")

Еще раз здравствуйте) ни у кого случайно нет дико тюнингованного конфига для Single Node кассандры ?) (Можно шутить про "в гугле забанили")

Щас тебе здесь посоветуют установить пять нетюнингованых и зашардить все )

Ну по идее 15 нетюнингованных Должны быть быстрее на чтение, верно?)

Ну по идее 15 нетюнингованных Должны быть быстрее на чтение, верно?)

как то сомнительно. я сделал проще. после записи жду когда станет доступно для чтения

Это как? Если после записи час подождать, то у меня на чтение запросы после этого быстрее выполняться будут или как?)

О, еще вопрос: кто-нибудь знает, как запустить кассандру in-memory. Я видел только как DataStax добавил такую фичу в свою сборку кассандры ( по их словам прирост в 10-100 раз был по скорости). Сейчас это как-то руками мб можно сделать, используя только MemTable?

И почему сомнительно? Я где-то читал, что там с добавлением узлов кассандры скорость чтения чуть ли не линейно повышается

Хотя мб я начитался статей и это не так работает)

Это как? Если после записи час подождать, то у меня на чтение запросы после этого быстрее выполняться будут или как?)

не часы. но иногда не сразу доступно для чтения. даже в рамках одной ноды. какие то миллисекунды

О, еще вопрос: кто-нибудь знает, как запустить кассандру in-memory. Я видел только как DataStax добавил такую фичу в свою сборку кассандры ( по их словам прирост в 10-100 раз был по скорости). Сейчас это как-то руками мб можно сделать, используя только MemTable?

она и так вроде в памяти живет почти целиком

И почему сомнительно? Я где-то читал, что там с добавлением узлов кассандры скорость чтения чуть ли не линейно повышается

скорость чтения там и так высокая. я про доступность свежезаписаных данных

https://gist.github.com/korotovsky/51135a9ededdba50ef4a6d63ab58517f

Оракл что ли?

Оракл что ли?

PG

А вы ожидали увидеть извращения на MySQL что-ли?)

не

https://gist.github.com/korotovsky/51135a9ededdba50ef4a6d63ab58517f

Зачем там PARTITION BY request_id если WHERE request_id = 'e85a7ba7-7313-44e0-a391-27e8b575187c'

Там позже будет IN ()

и чего IN?

request_id у тебя фиксированный в запросе, нафига тогда его в PARTITION?

WHERE request_id IN (...)