lloyd (09.07.2019 18:19, просмотров: 484) ответил Скрипач на Сейчас все лежит в одной таблице "дата/время - имя тега - значение". Индекс по дате/времени.-
- Запрашиваю несколькими SQL-запросами, с ограничением по диапазону дат и именем тега, по одному на запрос (точнее ORM для меня запрашивает). Глубоко не копал, не профилировал. Где почитать как и чем профилировать? - Скрипач(09.07.2019 18:50)
- Вот имя тэга запросто может тормозить, если это поле не индексировано. Лучше запросить только выборку по дате, а отсортировать по тэгу уже на локальном компьютере. Либо перед запросом строить индекс по нужному полю тэга. - бомж(09.07.2019 20:14)
- Лучше вспомнить про нормальные формы и разбить на две таблицы. Чтоб вместо имени тэга был ключ из таблицы с тэгами. Сравнивать по крайней мере будет числа, а не строки, при поиске. - fk0(10.07.2019 00:28)
- @#я! Если при разработке изначально не знать и не применять нормализацию (там, где это целесообразно), то результат - лотерея. В лучшем случае. - De_User(10.07.2019 01:11 - 01:16)
- Это поле тоже индексировано. Тонкое место в том, что и поле тега и дата-время не primary key (ибо не уникальны). Скрипач(186 знак., 09.07.2019 20:20)
- Индексов на датувремя и тег два? Или один составной? Если два, то есть вероятнось, что sql использует индекс по тегу, а надо наоборот. Если два индекса я бы их удалил и сделал один составной или удалил индекс на тег. Тегов около 500 особо выигрыша Ан(36 знак., 10.07.2019 11:08,
) - Уникальность не обязательна, мало на что влияет. Быстрее всего сделать запрос SQL для выборки данных во вспомогательную БД (например, по дате) и уже в ней "копаться" по второму и т.д. условиям. - De_User(09.07.2019 20:42)
- Сомнительно. Но нужно проверить. Всю дорогу считал что если все требования "помещаются" в один SQL-запрос, то это и есть самый быстрый способ. Скрипач(97 знак., 09.07.2019 20:49 - 20:57)
- То что я подсказал, применяют на очень серьёзных фирмах и очень ответственных базах данных. Это типовое решение. Ну и можно запрос с выборкой по двум критериям в хранимые процедуры засунуть. - бомж(09.07.2019 20:22 - 20:30)
- До трети запросов - с того же комьютера где лежит база. По ощущениям разницы времени обработки между локальным АРМ и удалённым нет никакой. Скрипач(114 знак., 09.07.2019 20:29)
- А покажите запросы к таблице, если не тайна - бомж(09.07.2019 20:31)
- Не тайна, но это запросы к ORM. Из них еще нужно подумать как SQL получить. - Скрипач(09.07.2019 20:33)
- А покажите запросы к таблице, если не тайна - бомж(09.07.2019 20:31)
- До трети запросов - с того же комьютера где лежит база. По ощущениям разницы времени обработки между локальным АРМ и удалённым нет никакой. Скрипач(114 знак., 09.07.2019 20:29)
- Индексов на датувремя и тег два? Или один составной? Если два, то есть вероятнось, что sql использует индекс по тегу, а надо наоборот. Если два индекса я бы их удалил и сделал один составной или удалил индекс на тег. Тегов около 500 особо выигрыша Ан(36 знак., 10.07.2019 11:08,
- Лучше вспомнить про нормальные формы и разбить на две таблицы. Чтоб вместо имени тэга был ключ из таблицы с тэгами. Сравнивать по крайней мере будет числа, а не строки, при поиске. - fk0(10.07.2019 00:28)
- Вот имя тэга запросто может тормозить, если это поле не индексировано. Лучше запросить только выборку по дате, а отсортировать по тэгу уже на локальном компьютере. Либо перед запросом строить индекс по нужному полю тэга. - бомж(09.07.2019 20:14)
- Запрашиваю несколькими SQL-запросами, с ограничением по диапазону дат и именем тега, по одному на запрос (точнее ORM для меня запрашивает). Глубоко не копал, не профилировал. Где почитать как и чем профилировать? - Скрипач(09.07.2019 18:50)