rPman

У тебя таблица work имеет смысл - факты исполняемой работы, а WhoWork - идентификатор Users, кто работает
но мне не понятна связь Work и Order, на схеме она есть но не видно какое поле из Work тут должно использоваться, id у них общий? но это не имеет смысла.

Чем должно являться пустое поле WhoWork? т.е. работа сделана но никем? это так же не имеет смысла и не понятно, по какому условию они должны попасть в результат? все пустые? - тогда добавь их к запросу union

p.s. настоятельно рекомендую провести рефакторинг и переименовать все поля, являющиеся идентификаторами foreign key, в имя_поля_id, при этом имя_поля по возможности должно быть именем таблицы (хотя не всегда это возможно, например две связи),т.е. в твоем случае WhoWork должно именоваться WhoWork_id или user_id.

В этом случае читать запрос и схему станет гораздо проще.

Тестировать - дома на своей виртуалке.

google: lowendstock
cheap budget vps

5-10МБ данные! не надо в базу данных, это плохо!

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

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

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

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

100 запросов в секунду - зачем такой нетипичной задачей грузить базу данных?

Задайся вопросом, сколько у тебя записей? миллионы? миллиарды? может эффективнее будет держать список id на бакэнде массивом и выбирать от туда?
* Запили миниатюрный сервис с сокетами, в который бакэнд при удалении или добавлении записи будет присылать id, а при перезапуске будет загружать весь список id... памяти это занимать будет порядка 16х от количества записей умножить на логарифм (зависит от того какие списки поддерживает бакэнд, нужно хранить упорядочный num -> id, причем это просто массива, при добавлении id добавляется в конец, а при удалении - на место удаленного ставится элемент с конца, к сожалению тогда для быстрого удаления нужен map: id->num).
* Списков таких должно быть несколько - свой по каждому значению веса (считается что вес - целочисленный и вариантов значений значительно меньше общего количества записей), соответственно каждый id попадает в свой список.
* Каждый раз, как идет запрос на случайный id, считаешь два случайных числа:
- первое на интервале [0..максимальное значение веса) - выбираешь какой вес сейчас сработает
это нужно делать с учетом вероятности, которое соответствует каждому весу, т.е. для каждого веса свой интервал значений случайного числа, для 1 это будет попадание между [0..1), для 2 - [1..3), для 3 - [3..6), для 4 - [6..10),.. макс значение интервала равно сумма арифметической прогрессии 1....N где N максимальное значение веса. Левое значение интервала для n считать по формуле суммы арифметической прогрессии а правое + значение веса для него.
- второе, [0..максимальное значение num в соответствующем списке)
второе число даст искомый номер в массиве, а значит и id.
* Для значений весов которые не используются (пустые списки id) нужно будет исключать такое число из списка доступных значений весов, делать новый список с меньшим количеством и давать соответствие значений их этого нового списка с меньшим количеством весов и общим, чтобы такие неиспользуемые веса не попадались.
К примеру из весов 1..10 используются только 1,4 и 10, тогда делаем получаем новый список из 3 элементов, но в формуле расчета интервала для вычисления правой границы использовать значение веса, т.е.:
[0..1), [1,5),[5..15) - общий интервал [0..15)

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

Трудоемкость алгоритма О(1) с очень маленькой константой, но требует память O(n)= n*log(n) с процессором O(n) log(n) на любые модификации.

p.s. Данный алгоритм можно реализовать и в базе данных, на тригерах, так как держать в оперативной памяти списки не требуется, причем базы могут быть отдельные от реальной (очень неудобно и повышенная нагрузка на процессор, лучше использовать key->value базы данных только как хранилище списков id)

Тригерами
если готов что за консистентность данных база данных не будет отвечать, используй что угодно

Воспользоваться нужно готовыми инструментами 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 меньше или больше, т.е. неверное значение.
Одно из решений, храните несколько последних значений подсчетов количества с датой их получения, а запрашивать эти данные только те, дата которых ниже даты запроса