"Это добавляет дополнительные расходы на операции с данными" - если много сложных индексов - это существенно замедляет вставку. От 1 индекса думаю ничего не ухудшится
des1roer: если нет индекса - да, конечно, он делает полный скан таблицы, т.к данные в ней не отсортированы. индекс это по сути отсортированный набор значений. по нему он быстро находит нужные записи
des1roer: "Получается динамически создавть индексы для данных последних дней не получится?" - создайте отдельную таблицу для данных последних дней. Все лишние записи из неё переносите в другую таблицу
des1roer: " но блокирует запись (вставку, обновление и удаление) до конца построения индекса"
создайте новую пустую таблицу. создайте в ней индекс.
переключите запись данных с датчиков на неё.
дозалейте в таблицу старые данные.
простой будет миннимален
Ну строго говоря использовать string можно все таки.
В mysql у decimal максимальное количество знаков после запятой = 65.
Соответственно если нужна бОльшая точность - выхода особо нет.
entermix: пардон, прикрепил кривую ссылку на хабр, обновил ответ.
если кратко то идей тут не много: либо явно строить какой то неразрывный ключ и выбирать из него по id between, либо найти какое то поле по которому можно делать подгрузку between хоть и не равными кусками. Например по дате-часу сообщения.
Сергей Протько: ну черт его знает, мне кажется что кране медленно.
Опять же поведение всяких свайпов итд не протестишь нормально, анимация в эмуляторе лично у меня лагает вся.
ditgeek: честно говоря никогда не возникало такой необходимости. сейчас попробовал - да, поиск какой то странный. если 2 слова ввести - он их ищет "AAA or BBB", но если 3 и больше - уже нет.
Надо погуглить про синтаксис поиска их, наверняка что то есть
