Добрый день!

Что-то торможу жестко...

Вот есть таблица, которая хранит свойства некого объекта вместе с историей их изменений:

update_id key value
1 x 2
2 y 1
3 z 8
4 x 7
5 x 5
6 y 2

Какой нужно сделать SELECT, чтобы получить все свойства объекта с их самыми последними значениями?

Т.е. чтобы после запроса получилось:

update_id key value
3 z 8
5 x 5
6 y 2

Подскажите плиз кто знает, как должен выглядеть такой запрос? Уже всю голову сломал

Здравствуйте, VmK, Вы писали:

VmK>Какой нужно сделать SELECT, чтобы получить все свойства объекта с их самыми последними значениями?

Для каждого key вытаскиваешь максимальный update_id. Затем вытаскиваешь строки по найденным id

Что-то тип такого (не проверял):

SELECT * 
FROM table
WHERE id IN (
  SELECT MAX(update_id)
  FROM table
  GROUP BY key
)

Если принять, что update_id увеличивается с каждым обновлением, то примерно так:

with cte as (
    select max(update_id) as last_update_id
    from history as h
    group by h.key
)
select h.update_id, h.key, h.value
from history as h
inner join cte on h.update_id = cte.last_update_id;

Здравствуйте, VmK, Вы писали:

VmK>Подскажите плиз кто знает, как должен выглядеть такой запрос? Уже всю голову сломал

В нормальном SQL похожий запрос может выглядеть примерно как

select key, max(value) keep (dense_rank last order by update_id)
from table
group by key

но гораздо правильнее он будет выглядеть так

begin
  drop эта_хрень;
  уволить_её_авторов;
  нанять_программиста;
end;

Спасибо огромное! То, что нужно!!!

Б>

Б>SELECT * 
Б>FROM table
Б>WHERE id IN (
Б>  SELECT MAX(update_id)
Б>  FROM table
Б>  GROUP BY key
Б>)
Б>

Здравствуйте, Softwarer, Вы писали:

S>но гораздо правильнее он будет выглядеть так

S>

begin
S>  drop эта_хрень;
S>  уволить_её_авторов;
S>  нанять_программиста;
S>end;

А кого конкретно уволить-то? Автора темы или авторов BigQuery?

Здравствуйте, Слава, Вы писали:

С>А кого конкретно уволить-то? Автора темы или авторов BigQuery?

К BigQuery у меня претензий нет (возможно, потому, что я с ним не работал). А вот зачем складывать данные так, чтобы для тривиального запроса требовалось завязываться узлом — вопрос, назовём так, открытый.

Здравствуйте, Softwarer, Вы писали:

S>К BigQuery у меня претензий нет (возможно, потому, что я с ним не работал). А вот зачем складывать данные так, чтобы для тривиального запроса требовалось завязываться узлом — вопрос, назовём так, открытый.

Обычно добавляют булевский столбец типа актуальные данные или нет.

Здравствуйте, Softwarer, Вы писали:

S>К BigQuery у меня претензий нет (возможно, потому, что я с ним не работал). А вот зачем складывать данные так, чтобы для тривиального запроса требовалось завязываться узлом — вопрос, назовём так, открытый.

А как удобнее было бы складывать данные?

Здравствуйте, vsb, Вы писали:

vsb>Обычно добавляют булевский столбец типа актуальные данные или нет.

И при добавлении еще менять булевый столбец, зачем?

Здравствуйте, Буравчик, Вы писали:

vsb>>Обычно добавляют булевский столбец типа актуальные данные или нет.

Б>И при добавлении еще менять булевый столбец, зачем?

Чтобы запросы делать не через одно место.

Здравствуйте, vsb, Вы писали:

vsb>Чтобы запросы делать не через одно место.

Обычный запрос, вроде.
С индексами будет работать очень быстро.

Здравствуйте, Буравчик, Вы писали:

Б>Обычный запрос, вроде.
Б>С индексами будет работать очень быстро.

Первые пару лет.

Здравствуйте, wildwind, Вы писали:

W>Первые пару лет.

Что произойдет через пару лет?
При каком количестве записей / объеме данных будут проблемы?

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, Слава, Вы писали:

С>>А кого конкретно уволить-то? Автора темы или авторов BigQuery?

S>К BigQuery у меня претензий нет (возможно, потому, что я с ним не работал). А вот зачем складывать данные так, чтобы для тривиального запроса требовалось завязываться узлом — вопрос, назовём так, открытый.

Ок. И так задача, хранить курсы валют и получать их на заданную дату.
Как будешь делать?

Одна таблица точно будет: период, валюта, курс.
Для ускорения, если есть потребность дергать данные ну прям очень быстро и это критично, можно сделать вторую: валюта, курс.
На первую повесить триггер и при записи/обновлении/удалении обновлять запись во второй таблица.

Так?

Теперь представь что дергать актуальные данные надо хотя и часто, в алгоритме где они нужны, время работы такого запроса меньше 1% времени. Все еще надо вторую таблицу делать?

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, Буравчик, Вы писали:

vsb>>>Обычно добавляют булевский столбец типа актуальные данные или нет.

Б>>И при добавлении еще менять булевый столбец, зачем?

vsb>Чтобы запросы делать не через одно место.

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

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, Буравчик, Вы писали:

Б>>Обычный запрос, вроде.
Б>>С индексами будет работать очень быстро.

W>Первые пару лет.

Вот смотри, ты уже вбросил данные про пару лет... При этом ты не в курсе задачи. Насколько там часто пишут данные. Насколько вообще важна история. Если там данные пишут не чаще раза в день, то оно и 100 лет будет работать отлично, всего то 300000 записей по одному свойству, да еще и индексом = 19 итераций поиска на каждое свойство.

Здравствуйте, wraithik, Вы писали:

vsb>>Здравствуйте, Буравчик, Вы писали:

vsb>>>>Обычно добавляют булевский столбец типа актуальные данные или нет.

Б>>>И при добавлении еще менять булевый столбец, зачем?

vsb>>Чтобы запросы делать не через одно место.

W>А булевский столбец мы будем триггером обновлять по все таблице... отличный вариант.

Чего? При редактировании записи проставляешь false отредактированной записи, true новой. Какой ещё триггер? Вместо одного insert получаешь insert + update. Отличий почти нет. А производительность select-ов небо и земля. Если партиционировать, то вообще разницы не будет.

Здравствуйте, Буравчик, Вы писали:

Б>А как удобнее было бы складывать данные?

А вот за ответ на этот вопрос архитекторы и получают свои зарплаты Тут уже начинается — сколько этих данных, какие запросы к ним будут стучаться, как часто и в каких масштабах изменения, где надо вносить изменения задним числом (!) и как это всё будет меняться в ожидаемом будущем. Свою долю вносят фичи конкретной СУБД.

В целом, есть два основных варианта:

а) Основные операции идут с актуальными данными, а исторические в основном лежат. В этом случае нужен способ эффективно отделять текущие данные от прочих. В простом случае это может быть вышеупомянутый булёвый столбец. Дальше начинаются соображения о том, что актуальным данным хорошо бы лежать физически рядом и на быстых дисках, а исторические хорошо бы убрать подальше и на медленные. Поэтому могут делать отдельную таблицу актуальных данных и отдельную — исторических. Могут, например, партиционировать таблицу на "актуальную" и "историческую" части. А могут держать таблицу как историческую, а для быстрого чтения актуальных сделать materialized view.

б) Основные операции идут "на указанную дату". В этом случае естественное решение — снабжать каждую строку периодом активности, date_from / date_to. Но если данных сравнительно немного, а меняются сравнительно часто, то иногда делают слепки каждый день (чаще всего так поступают с курсами валют). Ещё один интересный вопрос: когда меняется одно поле, делать новую версию для этого поля (как в исходном примере) или для всей записи. Тратится больше места, зато быстрее выборка. Бывает, что и в этом варианте актуальные данные нужны чаще среднего — и снова начинаются приседания из предыдущего пункта.

Здравствуйте, Softwarer, Вы писали:

S>А вот за ответ на этот вопрос архитекторы и получают свои зарплаты Тут уже начинается — сколько этих данных, какие запросы к ним будут стучаться, как часто и в каких масштабах изменения, где надо вносить изменения задним числом (!) и как это всё будет меняться в ожидаемом будущем. Свою долю вносят фичи конкретной СУБД.

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

S>В целом, есть два основных варианта:

Насчет архитектуры, имхо:
— надо проектировать исходя из текущих (обозримых) потребностей, а не городить суперсистему, которая способна на все
— в случае сомнения в выборе проектного решения, выбрать абстракцию и выделить выбранное решение в отдельный модуль/класс, чтобы можно было в дальнейшем легко изменить решение (например, для повышения быстродействия)