SalatProduction: у меня немного не до конца вырисовывается в голове полная картина, но с единовременными операциями в памяти пугают пороги в 2Gb, 4Gb и прочим (это я предположил что архитектура процессора x86|64)
Я имею в виду лить пришедшие извне данные в таблицу и уже дальше сливать-сравнивать средствами sql. Ну а подразумевая то, что изменения прилетают каждый раз "одноразовыми", то втянул - обработал - удалил
У меня в подобной конструкции (правда mssql) полмиллиона записей втягиваются булком из csv секунд за 5-7, а перед этим сек 20 конверт из mdb в csv (по ряду причин такая двухфазка), подопытный с 18 миллионами строк временно пропал. Вот дальнейшие действия (обновление-добавление позиций прайса) - пришлось оптимизировать, т.к. "в лоб" это занимало часы.
Николай Иванченко: А в чем проблема? номерок его есть? я в свое время напоролся на подобное, позвонил в поддержку - они мне объяснили по какую версию номерок действителен и пояснили где на сайте лежат прошлые версии.
ThunderCat: пока это 1-2 внутренних сотрудника - фиг бы с ним, ежели человек хочет "создать блог" - совсем не факт что писать туда будет только ответственный сотрудник
если же это "мой бложек на моем сайте" - дык хоть через phpmyadmin или cli ручками -)
marenco_victor: можно поиграться с предварительным (грязным) отбором по "близости" по одной из проекций: типа находим 1000 объектов с минимальной разницей X2-X1, потом 1000 по Y2-Y1 и уже на этой пересечении этих отборов считать корни из суммы квадратов.
бОльшая часть услуг юристов декларируется сразу и взыскивается сразу.
Да и в общем-то в рамках их присутствия судебных представителей - ценники вполне скромны.
p/s/ И да, стоит включить в свою философию еще внимательность: ну чтобы отличать топикстартера и комментаторов -))
множественное число п.11 и далее - предположительно подразумевает все-таки множество игр?
тогда как минимум имеет смысл держать таблицу с первичным ключом (игра, юзер) и там уже держать число игр, побед и прочую ерунду.
При необходимости сводного вывода - join'ить, суммировать, группировать
"KDJF39484 Автаматический выключатель" и "Афтомат KDJF39484" дадут огромную разницу, хотя партнамбер у них идентичен.
Но тут уже проблема архитектуры в которой код (уникальный или близкий к уникальному) почему-то живет вместе с названиями, описаниями и примечаниями.
Можно слегка "покостылять" и вычищать из сравнения коды элементов, точнее вычленять их (например сверяясь с каталогом) и для позиций с существующим и совпадающим кодом - давать "точное совпадение" независимо от остального текста.
Ну и тюнинг дальше - структура партномеров, т.к. зачастую код может состоять из уникального идентификатора + паразитных кодов (типа цвета, страны и т.п.)
Как образчики:
HP Microserver - 722320-B21 где B21 - собственно РФ
Гиперлайновский шкаф: TSA-3261-GD-RAL9004 - это черный по RAL (RAL9004), со стеклянной (GD) дверью шириной 600, глубиной 1000 мм и высотой 32юнита
соответственно для гиперлайна приоритеты сравнения должны были бы идти как TSA(серия) -> XXYZ(размеры) -> QQ (тип двери) -> RALcccc (цвет)
2017-01-17 12:55 не ПОПАДЕТ в between '2017-01-16' and '2017-01-17' !!!
( 201-01-17 12:55 > 2017-01-17 00:00)