Сортировка SQL результатов по дате на КЛИЕНТЕ, а не в ЗАПРОСЕ - PullRequest
Новая
       63

Сортировка SQL результатов по дате на КЛИЕНТЕ, а не в ЗАПРОСЕ

1 голос
/ 26 мая 2020

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

CREATE TABLE `userWeights` (
  `weight_id` int PRIMARY KEY AUTO_INCREMENT,
  `user_id` int,
  `weight` float,
  `date_created` timestamp
);

Очевидный вариант использования здесь - некоторая конечная точка REST getWeights (user_id), а затем отображение ее в виде графика в пользовательском интерфейсе. Стандартный запрос, который я бы написал, был бы примерно таким: 

SELECT * FROM userWeights WHERE user_id=user_id ORDER BY date_created ASC

, но, поскольку мы сортируем по дате, бизнес-лог c, который никогда не изменится для этого варианта использования, может ли сортировка вычислить load быть передан на устройство клиента и, таким образом, улучшить производительность запроса SQL? будет ли это незначительным улучшением, скажем, для таблицы из 1000 пользователей, в которой мы храним ежедневные измерения веса за 6 месяцев? 

SELECT * FROM userWeights WHERE user_id=user_id
results.sort(date_created, ASCENDING); //e.g. code on android device

РЕДАКТИРОВАТЬ: Я спрашиваю, потому что многие хосты облачных функций / облачных баз данных взимают плату в зависимости от время вычисления на вызов.

Ответы [ 3 ]

0 голосов
/ 26 мая 2020

Производительность фактической сортировки данных на стороне клиента и на стороне сервера незначительна - но обычно быстрее ближе к данным (выполняя это на сервере базы данных).

Однако есть некоторые другие вещи, которые следует учитывать при размышлении о том, где разместить сортировку:

  1. Ремонтопригодность - если вы поместите logi c на стороне клиента, то любой новый клиент, который вы добавляете, должен будет реализовать сортировку logi c тоже. Поэтому, если у вас есть веб-приложение, приложение iOS и приложение Android, вам нужно будет реализовать сортировку во всех трех приложениях, чтобы получить согласованный UX. Если вы хотите изменить сортировку во всех приложениях, теперь вам нужно не забыть сделать это в трех местах, тогда как если logi c находился в общем API или БД, вы можете внести изменения в одном месте.
  2. Доступность - Как вы сказали, облачные провайдеры могут взимать плату за время вычислений. Если это вызывает серьезную озабоченность, вы можете переместить сортировку на стороне клиента, но, как я уже сказал ранее, ремонтопригодность в будущем потребует значительных усилий, которые будут стоить вам времени разработчика и, следовательно, долларов в будущем. Я бы порекомендовал выяснить, насколько удобство сопровождения импорта для вас по сравнению с доступностью, и действительно ли перемещение клиентской части сортировки поможет доступности в долгосрочной перспективе.
0 голосов
/ 31 мая 2020

KISS.

Добавление ORDER BY к запросу просто и сложно ошибиться.

Добавление сортировки к клиенту требует большего количества нажатий клавиш и более подвержено ошибкам.

Кроме того, можно съесть свой торт, даже не заплатив за это! Сортировка может быть «бесплатной»: 

CREATE TABLE `userWeights` (
  `user_id` int,
  `weight` float,
  `date_created` timestamp,
  PRIMARY KEY(user_id, date_created)
);

Вам по-прежнему нужно предложение ORDER BY в SELECT, но обратите внимание, что это потребует ноль усилий для либо сервер или клиент.

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

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

Экономия затрат ...

  • Оптимизатор не будет взимать плату за обнаружение того, что данные уже отсортированы. (Вверху)
  • Не говорите SELECT *, что возвращает все столбцы; вам нужно только два: SELECT date_created, weight.

Проблема синтаксиса: WHERE user_id=user_id - Один из них должен быть входящим параметром. В противном случае он эквивалентен «ИСТИНА».

0 голосов
/ 26 мая 2020

В общем, сортировка будет быстрее на сервере базы данных, чем в клиентском приложении.

В ваших двух сценариях ios объем данных, передаваемых между базой данных и клиентом, является тем же. Единственная разница - это накладные расходы на сортировку.

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

...