rPman

Воспользоваться нужно готовыми инструментами mysql spartial, кажется форматы там популярные, найти готовые либы для работы с ними из браузера будет не сложно.

Если самим делать - главное не хранить в базе данных точки полигонов в записях - только целые полигоны, сериализованные в blob/text, причем сразу в формате, с которым будет работать браузер. В таблице в колонках можно хранить максимум координаты области (квадрат), описывающий полигоны объекта (тогда задача бакэнда будет всего навсего выбор полигонов по условию попадания в нужные пределы и выдачу данных - основная нагрузка тут только на сеть).

Еще, нужно подготовить в базе данные сразу для нескольких уровней детализации, чтобы при уменьшении масштаба не получить разом огромную нагрузку и миллионы объектов, группируйте объекты в более крупные, уменьшая их количество (дома в кварталы, кварталы в районы, потом города, облести и т.п.). Это можно сделать просто дополнительными слоями, скрывая ненужные по мере изменения масштаба.

Не нужно забывать и о проекциях, мир не на плоскости у нас, а значит запросы на попадание полигона в прямоугольник экрана становятся не простыми.

Файл импорта - это обычный текстовый файл, его можно спокойно редактировать или пропускать через фильтры потоковые sed/awk/grep/... удалите ненужные строки с drop из этого файла и импортируйте уже таким

Какого фига вы рекомендуете человеку удалять гланды через задницу. Какой вебсокет в mysql вы что? Какие тригеры.

Бакэнд является единственным, кто должен менять критичнуюинформацию в базе, вот пусть он и рассылает в вебсокет нужную информацию клиентам.

Вебсокет сервер это пять строчек на php, пара строк на клиенте и легкие рукошевеления для настройки автозапускаемой службы. Если вебсокет уже есть то делать ничего не надо. Придумываете тип сообщения, которое сервер будет слать по этому вебсокету клиентам, клиенты его не должны отображать а вместо этого запрашивать информацию тем старым методом, которым вы сейчас ежесекундно обновляете данные. ВСЕ.

Когда клиент дает цену товару, бакэнд смотрит, какие клиенты его покупают и шлет им сообщение. Возможно придется держать в памяти массив - какой клиент в базе = клиент вебсокет, но с вероятностью 99.(9)% это уже сделано (как минимум имя отображать и авторизация)

select * from table1 union select * from table2

Вы закачиваете ВСЮ таблицу и построчно анализируя ее делаете апдейты по одной строчке, тут поплохеет любому серверу. Во первых почти наверняка всю логику можно просто засунуть в запрос, так как там проверки по простому условию на дату. Во вторых, я не изучал код, если это сложно реализовать в sql, то хотя бы не делайте update по одной записи, собирайте id необходимых записей и обновляйте пакетом либо через временную таблицу либо через инлайн данные тупо через where id in (список id)

p.s. не пытайтесь везде работать с датами как дата в виде строки, это всегда неудобно, половина кода у вас парсинг строки с датой... работайте с __int64 date timestamp, зачастую это самый удобный тип данных.

Можно ли микроволновкой гвозди забивать?

mysql не предназначена для передачи сообщений - это инструмент хранения и анализа данных.

Конечно, сделать можно все что угодно, вы программист или кто, но зачем? эффективность реализации будет ниже плинтуса.

p.s. у разных баз данных есть штатный механизм рассылки нотификаций клиентам, но именно у mysql его нет, реализуется плагинами, правда, внезапно, там будут те же сокеты :)

Не обязательно все делать именно в mysql так что если я говорю база это значит может быть в т.ч. к примеру локальные переменные сессии веб-сервера.

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

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

Человека идентифицируйте сессией, понятие сессия есть во всех фреймоврках для вебсервера, например php - смотрите session_start()

Во первых, с чего вы взяли что сервер не будет справляться?
Во вторых шардинг дает только линейную оптимизацию нагрузки, т.е. позволяет распределить нагрузку на несколько серверов.

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

Сложную аналитику же проводите оффлайн сторонними средствами, ибо sql базы для этого не подходят.

Добавление тысяч идентификаторов в sql запрос вида where in (...) это плохая практика, что получается, если вы сначала заполняете in nmemory таблицу идентификаторами (из полнотекстового запроса внешней базы), а потом уже делаете фильтрацию по вашим атрибутам из sql базы, приджойнив это временную табличку?

зы, пагинацию делать только через - получаете список id всех записей (отфильтрованные и отсортированные как надо), сохранив во временной таблице по сессии пользователя, а затем уже подгружаете данные окнами. Никаких limit для тяжелых запросов!

Если загрузить весь список не представляется возможным или загрузка данных даже в текущем окне тормозная (мало ли вы интернет индексируете), то делайте предзагрузку нескольких страниц вперед, и при переходе по ним запускаете фоновым сервисом загрузку новых, это повышает нагрузку на сервер в разы но значительно увеличивает отзывчивость для пользователя.

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

Если вам нужна скорость, то уходите от постоянного переподключения к сервисам.

Конечно, современные веб-сервера и браузер умеют переиспользовать подключение для http rest, но это стоит перепроверить в вашем случае. Если идут постоянные переподключения то высокие пинги могут превратить работу вашего сервиса в лагучую дрянь (один https добавит пару туда-сюда отправлений).

websocket изначально по определению однократно открывает подключение а затем использование открытого канала возможно в обе стороны (с http rest только в одну и с оговорками в сторону клиента, читай не эффективно).

А еще вопрос, как у вас организован код обработки http rest. Если это старый классический подход, когда на каждый запрос запускается php скрипт это это еще и высоченная нагрузка на сервер, переделывайте (а точнее убирайте эту фигню и оставьте websocket), так как разница подходов дает ускорение на пару тройку порядков (это не шутка и не преувеличение).

у http rest только одно достоинство - почти бесплатная горизонтальная масштабируемость на сервере.

Настоятельно рекомендую, все, что гуляет через интернет, заворачивать через http (в т.ч. websocket), само собой лучше с шифрованием (https), меньше будет гемороя, так как провайдеры (россия), а чаще мобильные, старательно тормозят или даже блокируют остальной трафик (например почти полностью убит p2p, даже webrtc испоьлзовать нужна магия).

Вернее сказать, тот трафик, которые DPI у провайдера не понимает, может быть сильно ограничен или даже сломан (лезут кривыми руками куда не следуют), поэтому не изобретайте паровоза.

На базе http берите либо готовые фреймворки и сериализаторы либо изобретайте свое. Популярные направления, использовать json, xml а если бинарный то Protobuf (вообще универсальная вещь). Для любого из указанных примеров в java есть библиотеки.

Если вышеописанные советы (заливаете данные во временную таблицу а потом delete + insert + commit) будут сильно нагружать базу, попробуйте вместо удаления делать update (имеет смысл если ваш скрипт единственный, кто правит данные, тогда не придется блокировать таблицу), однозначно это будет на порядок быстрее, так как почти наверняка в старых данных и в новых изменения минимальны (цены и небольшое количество новых и удаленных товаров).

Убирайте пиздец с вставкой значений в sql-код, пользуйтесь параметрами запросов. Иначе к вам приедут sql injection.

По поводу значений формы, вам достаточно использовать условия в вырожениях, что то типа
@$_POST['vidrab']==''?null:$_POST['vidrab']
@ говорит что ошибку отсутствия нужно игнорировать, и значение в этом случае будет false, нестрогое равенство == скушает вместе с false еще и пустую строку. Если у вас комбобокс, то используйте конкретное значение 'не выбрано' и сравнивайте дополнительно с ним. Осторожнее с чекбоксиками, там отключенное значение - пустое.

КЛАДР
https://dadata.ru/

Если баз МНОГО то не только считайте количество тригерами, но и делайте запросы в базу асинхронными, иначе даже после десятка баз последовательный запрос будет выполняться секунды.

Еще есть практика кеширования данных и инвалидация кеша при возникновения событий (тригерить события notify на клиент - методы есть), т.е. делать запрос только в те базы, по которым пришел notify (тут же и проверять).

p.s. будьте осторожны, несколько баз работают независимо и не умеют транзакции, т.е. количество может измениться в процессе чтения и к примеру если вы перемещаете объект между базами, суммарное количество объектов не изменилось (тут убрали там добавили) но при запросе количества можно получить на 2 меньше или больше, т.е. неверное значение.
Одно из решений, храните несколько последних значений подсчетов количества с датой их получения, а запрашивать эти данные только те, дата которых ниже даты запроса

У вас там везде стоит limit 1, боюсь это никак эффективно не агрегировать

Но если у вас реально большие данные, в некоторых случаях можно добавить дополнительную логику в базу, когда в специальной таблице тригерами вычисляются необходимые значения (например можно хранить id записи с минимальным значением и каждое следующее новое проверять с прежним минимумом, тогда не надо будет в тригере постоянно минимумы искать, т.е. трудоемкость O(1)), соответствующих условию, сами понимаете что итоговая нагрузка будет ложиться не на чтение а на вычисления во время записи в таблицы.

Ваш пример простой а значит предложение с тригерами - вполне подходит.

используйте полное имя с таблицей `CB`.`sb0002_lb0003_id` а не алиас
а еще у вас там двойная вложенность запросов, избавляйтесь от этого п...ца, тем более в вашем случае все легко выносится в where без вложенностей

На вопрос как хранить нужно отвечать только после того как вы ответите на вопрос, как вы хотите это читать. Нужна ли фильтрация по этим полям или поиск например и т.п.

В зависимости от этого ответа и будут рекомендации. mysql с текстами работает без проблем, есть инструменты поиска и т.п. Храните все там как есть и не изобретайте себе проблем.

p.s. предвещая вопрос, если текстами являются например тяжелые книги (к примеру база librusec) то хранить файлы в самой базе - бессмысленно и даже вредно. Т.е. если вам не нужно разбирать содержимое текста, вам в принципе все равно как хранить, но базы данных могут давать дополнительный (небольшой) оверхед по используемому месту и даже на чтение, по сравнение с обычными файлами (исключение - когда их миллионы, там могут возникнуть проблемы из-за выбранной файловой системы).

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

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