Это файл проекта.
image.png
Помогите оптимизировать код (запросы к БД)
-
This post is deleted!
-
@doupiu said in Помогите оптимизировать код (запросы к БД):
С этого момента все потоки из режима "проверяем наличие" переходят в режим "покупаем товар".
Не проще использовать ресурс или глобальную переменную
-
@UserTrue said in Помогите оптимизировать код (запросы к БД):
Не проще использовать ресурс или глобальную переменную
Как и написал, решение очевидное, но не подходящее, к сожалению. Товаров не 1, а сотня. У каждого товара есть еще десяток параметров, влияющих на дальнейшую работу скрипта. Поэтому все хранится в БД.
-
@doupiu said in Помогите оптимизировать код (запросы к БД):
@UserTrue said in Помогите оптимизировать код (запросы к БД):
Не проще использовать ресурс или глобальную переменную
Как и написал, решение очевидное, но не подходящее, к сожалению. Товаров не 1, а сотня. У каждого товара есть еще десяток параметров, влияющих на дальнейшую работу скрипта. Поэтому все хранится в БД.
Если все скрипты работают на одном сервере:
- Стартуют потоки с поиском товара.
- Товар найден, данные пишутся в базу.
- Этот же скрипт запускает любым способом другой функционал, который покупает этот товар. Например, это может быть функция в BAS.
Вероятно, изначально был написан скрипт с поиском товара, потом с его покупкой. И это все отдельные сущности.
Потом между ними поставили БД для обмена информацией. Но возникли нюансы.Я всегда перед тем, как писать скрипты, пишу документацию, что я делаю, зачем я это делаю и как я буду это делать.
В какой-то степени это помогает мне уложить в голову задачу и избежать части архитектурных ошибок.
Перед тем, как писать какой-то код, я уже знаю почти все о будущем скрипте.Чтобы приобрести такой навык, нужен опыт. Иначе придется постоянно переделывать что-то, что бывает мучительно.
-
@doupiu said in Помогите оптимизировать код (запросы к БД):
@UserTrue said in Помогите оптимизировать код (запросы к БД):
Не проще использовать ресурс или глобальную переменную
Как и написал, решение очевидное, но не подходящее, к сожалению. Товаров не 1, а сотня. У каждого товара есть еще десяток параметров, влияющих на дальнейшую работу скрипта. Поэтому все хранится в БД.
Если товаров сотня, то использовать глобальную переменную возможно, а вот если объёмов товара больше, то только бд. Создайте массив с объектами со свойствами, как столбцы в базе данных. При добавлении данных в базу дублируйте данные в глобальную переменную.
Ограничивайте количество элементов в массиве, например держите не более 100 элементов. Также можете сохранить хеш объекта в отдельное место, например во вторую глобальную переменную. Это нужно, что бы потоки ждали изменения хеша при добавлении новых данных, а не выполняли проверку по кругу со старыми данными.
-
-
@sergerdn said in Помогите оптимизировать код (запросы к БД):
@Fox said in Помогите оптимизировать код (запросы к БД):
Если товаров сотня, то использовать глобальную переменную возможно,
Можно хранить в глобальной переменной только id товара в базе. Тогда будет существенная экономия памяти.
Если необходим поиск по каким то параметрам, то их лучше добавить в объекты
-
@Fox said in Помогите оптимизировать код (запросы к БД):
@sergerdn said in Помогите оптимизировать код (запросы к БД):
@Fox said in Помогите оптимизировать код (запросы к БД):
Если товаров сотня, то использовать глобальную переменную возможно,
Можно хранить в глобальной переменной только id товара в базе. Тогда будет существенная экономия памяти.
Если необходим поиск по каким то параметрам, то их лучше добавить в объекты
Я бы все равно добавлял только id товара, а в скрипте покупки уже дергал бы из базы и делал нужные проверки. Так как, вероятно, там уже это все есть.
Но это на усмотрение конкретного девелопера.
-
@Fox said in Помогите оптимизировать код (запросы к БД):
@doupiu said in Помогите оптимизировать код (запросы к БД):
@UserTrue said in Помогите оптимизировать код (запросы к БД):
Не проще использовать ресурс или глобальную переменную
Как и написал, решение очевидное, но не подходящее, к сожалению. Товаров не 1, а сотня. У каждого товара есть еще десяток параметров, влияющих на дальнейшую работу скрипта. Поэтому все хранится в БД.
Если товаров сотня, то использовать глобальную переменную возможно, а вот если объёмов товара больше, то только бд. Создайте массив с объектами со свойствами, как столбцы в базе данных. При добавлении данных в базу дублируйте данные в глобальную переменную.
Какая разница сколько их, можно все так же использовать ресурс в котором каждый товар это будет json строка и тп, вариантов масса. Это лучше чем 50 потоков долбят бедную БД. А еще обращение к встроенной БД синхронное!! тоесть все 50 потоков не могут одновременно к ней обратиться. Я думаю это было сделано для упрощения взаимодействия не особо продвинутых юзеров. Фактически при очень частых обращениях как у вас это приведет к сильному снижение скорости работы скрипта и подвисаниям интерфейса
-
@Fox @sergerdn @UserTrue спасибо за пищу для размышлений
Пока придумал такую архитектуру: при появлении товара в наличии вместе с изменением БД изменяем глобальную переменную IS_EXISTS_STOCK c false на true, что фактически сообщает нам, что "что-то в БД поменялось". Цикл соответственно постоянно проверяет только IS_EXISTS_STOCK, и только когда IS_EXISTS_STOCK=true - уже лезет в БД выяснять, что там изменилось.
Посмотрим :)
