MySQL. Что быстрее: много маленьких выборок, либо мало больших выборок?

MySQL скорость база данных выборка

Есть скрипт для синхронизации данных из прайс-листа (Excel, около 5000 строк) с базой данных (MySQL). Ежедневно их надо синхронизировать, при этом данные из прайса заносятся в базу данных с проверкой. По существующим данным обновляется только цена, несуществующие в базе данных добавляются, существующие в базе, но отсутствующие в прайсе - удаляются.

Как лучше сделать:
1 вариант. Взять все данные из БД одним запросом и обрабатывать массив данных, сравнивая построчно с прайсом.
2 вариант. Брать одну строчку из прайса, искать товар с нужным артикулом и сравнивать его.

В первом случае используется огромный объем памяти, во втором много запросов. Какой вариант лучше или может быть надо использовать другой вариант? Лучше - по скорости работы и надежности.
Ответы:
1ый вариант предпочтительнее. Аналог - аброботка запросов с меньшим количеством таблиц много быстрее чем обработка такого же кол-ва позиций, но с большим кол-вом таблиц.
1й вариант быстрее. 5000 строк один раз в день тфу для сервера, можно и вторым вариантом воспользоваться, если так будет проще писать. :)
В идеале нужно стремиться к тому, чтобы было лишь одно место хранения данных, что исключает необходимость синхронизации.
Т.е. в вашем случае может быть возможно избавиться от прайс-листа в Excel, если иметь веб-интерфейс для обновления информации, печати прайс-листа и, может быть, экспорта в файл.
Если же говорить о ваших двух вариантах то проже попробовать оба и выбрать что лучше. 5000 строк не так и много и возможно более надежный алгоритм предпочтительнее более быстрого.
Быстрее 1ый вариант, особенно если БД все вернет в отсортированном виде. (А данные там так и надо хранить).
Если отсортируешь еще и эти 5000 строк, то трудоемкость будет
O(5000*log2(5000)) - сотрировка + O(5000+N) - слияние.
Уточню, первый вариант быстрее если
5000+N < 5000 * log2(N)
Уже при N большем 100000 второй вариант быстрее
И еще одно уточнение, при небольшом N (до 100000) данные можно организовать так,
что поиск будет идти почти за константное время. Тогда 2ой вариант будет тоже будет быстрее.
Свистунович, насколько я понял постановку задачи, N ~= 5000 ("существующие в базе, но отсутствующие в прайсе - удаляются").
2  PureVirtual
Вы правы, про удаление записей я как то упустил. Значится N = 5000.
Тогда надо ли синхронизировать? Не проще ли каждый раз но новому создавать таблицу?
Предлагаю такой вариант решения. Ввести в таблицу БД дополнительное поле `Date` (дата добавления записи). Каждый день тупо сбрасывать в БД весь прайс из Excel'я, а затем удалять слишком старые записи (например, давностью более месяца). При этом в БД будет храниться не только текущая информация, но и статистика изменений за некоторый период времени. При выборке же актуальной информации брать последнюю дату по каждой конкретной записи, либо просто все записи за текущее число.
Не знаю, как для MySQL но для MSSQL в котором я немного разбираюсь - это семечки.  
Не знаю, что Вы имели в виду под надежностью: алгоритмы бывают или корректные или нет, реализации - аналогично.
Но прошу отметить, что мой способ
1. Краток. Тяжелее сделать ошибку в реализации
2. Прост. Тяжелее сделать ошибку в реализации
Из этих факторов вытекает невысокая необходимость вставлять корректную обработку разных исключений (например, потерю коннекта) в кучу мест
2 Easy
Как я понял из задачи здесь не синхронизация, а репликация данных из Excel.
Тогда cравнивать ничего не надо и Ваш вариант можно упростить.
Господа, уточню. Удалять все данные из БД при обновлении нельзя. В БД находится товарный каталог, в котором есть описание товара, набор полей, цена, количество и т.д. А по прайсу обновляется только цена и количество в случае наличия товара в прайсе и БД, либо добавляется новый товар с названием, описанием, ценой и количеством, если такого товара еще нет. То есть при обновлении создается отсутствующий товар, потом приходит менеджер и добавляет еще информации к новому товару - картинки, более развернутое описание, забивает всякие свойства, задает код и т.д.
1. Загрузить новый прайс во временную.
2. Сделать UPSERT
3. Удалить отсутствующие в новом прайсе через EXISTS или LEFT JOIN
однозначно: первый вариант.. это рациональный подход..


18 лет назад

RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.

Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.

Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.