Что быстрее: Javascript обработка или дополнительный запрос в MySQL?

Рейтинг: 0Ответов: 1Опубликовано: 23.09.2014

Всем доброго!

Есть в БД таблица -А- : | id | field0 | field1 | field2 | field3 |

Теперь мне нужно, чтобы информация из field1, field1 и field3 хранились в field0, при этом сами столбцы field1, field1 и field3 я удалю. Таблица -А- : | id | field0 |

Из html через Javascript я обращаюсь в БД, чтобы вытащить информацию о какой-нибудь строке (по id). Какой вариант будет эффективнее с точки зрения скорости:

  1. Я создаю таблицу -В-: | id1 | field1 | field2 | field3 | , при этом идентификатор строки id1 прописывается в field0 таблицы -А-. Преимущества: не нужен обработчик, все данные передаются как есть. Недостаток: в два раза больше записей и дополнительная таблица - дополнительные запросы.

  2. Я эти поля храню как массив в поле field0 таблицы -А-, в формате типа JSON: field1:значение, field2:значение, field3:значение. Однако для распаковки массива будет работать обработчик JS. Преимущества: Одна строка, одна таблица. Недостаток: время на распаковку.

Старался объяснить понятно, но если что не так, я дополнительно объясню)

Чуть не забыл:

  • в БД около миллиона записей;
  • запросы редкие, пакетами по 5-10 в секунду.

Ответы

▲ 1

Соединять колонки в одну не надо.

В обоих случаях выполняется один SQL-запрос. Или запрос выбирает 10 колонок (id + 1, 2, 3, ... 10) или выбирает две колонки (id + {1, 2, 3, ..., 10}) - разницы в скорости, на малых размерах полей не будет. Если же типами данных является nvarchar(100), например, то разница будет несущественной, что две колонки прочитать, что двадцать две.

Выигрыш в скорости возможен, если используется тип text, blob - тип, который хранится не в самой таблице, а за её пределами, в системной таблице. Чтобы считать десять значений типа text, движок СУБД сделает десять чтений из системной таблицы. А чтобы считать одно значение типа text - одно чтение. Тут разница есть.