LINUX.ORG.RU

каким mysql запросом связать строки из двух таблиц у которых между собой нет жесткой связи по полю id?

 


0

1

есть две таблицы в двух базах, сервер один.
в таблицы данные попадают с разных серверов у которых может отличаться время - до 5-10сек (не принципально на самом деле).
Как правильно связать строки из разных таблиц у которых два поля совпадают, а третьи поля таблиц «время» могут отличаться до десятков секунд

★★★★

Последнее исправление: Vlad-76 (всего исправлений: 1)

Ответ на: комментарий от Anoxemian

и по третьему полю 'время' нужно связать. Эти поля не ,бьются точь в точь , в интервале как то нужно с переводом полей в формат UNIXTIME,

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

и еще добавлю, ИНТЕРВАЛ ВРЕМЕНИ в котором ищутся записи в разных таблицах ИЗВЕСТЕН, как и значения двух полей.

Vlad-76 ★★★★
() автор топика
Последнее исправление: Vlad-76 (всего исправлений: 2)
Ответ на: комментарий от Anoxemian

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

Как запросом можно упорядочить по возрастанию строки одной таблицы по полю datetime, затем упорядочить так же строки второй таблицы, а после слить в одну таблицу ? ( с учетом того что число строк в таблицах одинаковое за период, если разное то непонятки)

Vlad-76 ★★★★
() автор топика
Последнее исправление: Vlad-76 (всего исправлений: 1)
Ответ на: комментарий от Vlad-76

Разница по AVG?

Если у тебя контролируемый интервал и в него попадает больше 2х записей, сделай разницу от AVG. С оконными функциями все плохо(

Anoxemian ★★★★★
()
Последнее исправление: Anoxemian (всего исправлений: 1)
Ответ на: комментарий от Vlad-76

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

ya-betmen ★★★★★
()
Ответ на: комментарий от Vlad-76

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

Vlad-76 ★★★★
() автор топика
Ответ на: комментарий от ya-betmen

Могут быть и по две и по три строки в левой и правой таблице которые попадают в интервал, может даже в левой быть 2 строки а в правой 3. Сматчить их на 100% не получается пототому что время в левой и правой табличке не совпадает.

Vlad-76 ★★★★
() автор топика
Последнее исправление: Vlad-76 (всего исправлений: 1)
Ответ на: комментарий от Anoxemian

AVG - это же среднее по нескольким значениям, к нему нужно GROUP BY? Разбежка по времени между строками левой и правой таблицы 1-5 секунд, а интервал времени для поиска строк может быть в 10-20 раз больше разбежки.

Vlad-76 ★★★★
() автор топика
Ответ на: комментарий от ya-betmen

Подсказывали выше, оставить в выводе запроса c JOIN строки таблиц у которых минимальное расхождение между таймстампами. Хотя по какому условию отфильтровать эти строки, тоже вопрос.

Vlad-76 ★★★★
() автор топика
Ответ на: комментарий от Vlad-76

минимальное расхождение между таймстампами

Ну это уже условие, но это точно те строки? Если да, то можно через подзапрос или ЦТЕ (хз что у тебя за база) населектить строки где дифф минимален.

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 2)

между собой нет жесткой связи по полю id?

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

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от Psilocybe

кто сказал, что проблема в этом лол

ясен пень что если в этом, то чинить надо её но и в этом случае не факт что это возможно.

Обст-ва за пределами ОП ясно дело на совести адекватности ТСа.

mrjaggers
()
Ответ на: комментарий от Psilocybe

Возможно и так, я (бегло) прочитал это по-другому - ТС очень экономно расходует знаки препинания.

Остальное не меняется - починка этого легко может быть за пределами возможностей ТСа.

У самого на работке сервак с левым временем. Я к этому отношения не имею никакого.

mrjaggers
()
Ответ на: комментарий от mrjaggers

Ну тогда задачу надо решать фундоментально, пригласить DBA и бормоча «консистентность», «формальность», «строгость» запилить правильную бд, лить данные в нее и селектить оттуда.

Anoxemian ★★★★★
()
Ответ на: комментарий от Anoxemian

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

Тут всё просто - чинить это, либо делать, как я выше написал. Какие ещё вар-ты не знаю.

mrjaggers
()
Последнее исправление: mrjaggers (всего исправлений: 1)
Ответ на: комментарий от crutch_master

я согласен, что говно. если в левой таблице три строки, а в правой две. вот и случилось говно.
введение уникального id для двух таблиц потребует переделать систему, переместить начальную точку генерации событий, чтобы появился этот уникальный id.
А это меняет очень много и сколько времени займет разработка и отладка ХЗ.

Vlad-76 ★★★★
() автор топика
Последнее исправление: Vlad-76 (всего исправлений: 1)
Ответ на: комментарий от Vlad-76

в левой таблице три строки, а в правой две

а можно для любопытных пояснить - что вы на выходе ожидаете? LEFT, RIGHT, CROSS, FULL ?

Какой результат-то считаете правильным? три? две? пять?

И поле с меткой времени какое ожидается на выходе? минимальное в допустимом интервале? максимальное? среднее?

Toxo2 ★★★★
()
Последнее исправление: Toxo2 (всего исправлений: 1)
Ответ на: комментарий от Vlad-76

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

Vlad-76 ★★★★
() автор топика
Ответ на: комментарий от Toxo2

«а можно для любопытных пояснить - что вы на выходе ожидаете? LEFT, RIGHT, CROSS, FULL ?» - это для меня не понятно.

в принципе - время не так сильно между серверами разбегается, не думаю что больше чем 5 сек за сутки. так что наверное так и сделаю пока, если меньше 5 сек разбежка, то эти строки и буду за правду принимать.

Vlad-76 ★★★★
() автор топика
Последнее исправление: Vlad-76 (всего исправлений: 1)
Ответ на: комментарий от Vlad-76

введение уникального id для двух таблиц потребует переделать систему, переместить начальную точку генерации событий, чтобы появился этот уникальный id.

У тебя там микросервисы штоли?

crutch_master ★★★★★
()
Ответ на: комментарий от Vlad-76

введение уникального id для двух таблиц потребует переделать систему

Да так-то связать два события - задача тривиальная, надо только прорваться через сраку уже написанного.

crutch_master ★★★★★
()

а если джойнить по двум полям и времени окрулив его до минут например? можно делать это форматированием в строку, взятием целого от результата деления или какой-нибудь специальной функцией

Syncro ★★★★★
()
Ответ на: комментарий от Syncro

а если джойнить

ТС так и не рассказал свою задачу.

Возможно тут вообще не JOIN, а UNION.

типа: «есть два лога событий из разных источников в разных БД, хочу получить из них один лог, в котором при совпадении полей 1 и 2 считать события в рамках 5 секунд как одно»

тогда что-то вроде timediff(c3, LEAD(c3)) над UNION обеих таблиц, наверное.

Toxo2 ★★★★
()