Как лучше спроектировать или что вы используете?

Question

[Саша]

Как обрабатывать большое количество динамических данных.

Вот к примеру возьмем магазин, у которого есть возможность отложить товар (забронировать).
Этот магазин состоит из :(2-3 магазинов + склад) может и больше "не суть"

Таблица:count
(id| shop1| shop2| shop3| sklad| reserve| well)
( 1|     3|     0|    11|     1|       5|   10)

Тут будет хранится кол-во находящихся в каждом магазине и складе, резерв и доступно всего(.

Теперь самое сложно, надо как-то собирать и обрабатывать все это, сложность возникает, когда бронируют по 2-3 товара толпой пользователей. Как с этим быть? Использовать редис? не подходит. Обратится к php, нагрузка большая, если только через js.
И после отправлять, но это сработает если будет 100 пользователей, а если 1000000, по любому возникнет ошибка, надо замораживать значение изменяемой ячейки(дабы в mysql есть такая возможность, но тут снова проблема, большая очередь, будут тормоза.)
Заранее, я взял интернет магазин для примера, что бы объяснить проблему, могу придумать другой пример если кому-то не нравится, но это наглядный.

Comments

[Viktor Vsk]

Сначала обратил внимание на сумбур в мыслях, потом заметил SEO в подписи. Все очевидно. Гуглите "Преждевременная оптимизация".

[sitev_ru]

А если на C++ написать? Поможет?

[Саша]

Да не, это я так, саморазвитие.
Я вроде бы додумался как подобное делают, но это все в теории.
Создать 3 функции, каждая из которых записывает в резерв и морозит.
Вторая подтверждает и списывает окончательно
и третья (очистка, истечении вр.) просто удаляет записи там где не нужны, а остаток списывается обратно.
Только для этого нужна таблица по типу
резерв(id_user| prod_id| count| data end) вроде бы ничего, не забыл.
теперь надо как-то сгруппировать данные.
Достаточно просто подумать, нарисовать пару листов схем и вот решение)

[Саша]

Виктор Ablebeam: Преждевременная оптимизация, это когда что-то уже есть, а не когда это в голове.
Я в веб-студии работал пару лет, так что знаю.Этот вопрос родился из-за интереса как это работает. Думаю что вам порой тоже интересно, как что-то работает. А так и интерес удалил и мозг размял.

[Саша]

sitev_ru: да сам по себе алгоритм важен. С++ мощный язык, понятно что там 100 строк кода могут базу новую создать.
Я плохо знаю с++, только php кое как, на уровне понимания, что-то дописать и спс шпаргалкам, которые помогают стоить грамотные...
А то некоторые могут отправить 100 запрос, что бы достать 100 строк, в место одного.
Я по части js. К увы, тут он не особо полезен. Если только составить грамотный запрос.

[Илья Босенок]

Виктор Ablebeam: это не преждевременная оптимизация. Это нормальных подход к проектированию. Зачем тратить в будущем десятки человека часов на переделку и костыли, когда можно сразу нормально спроектировать? Не говоря уже о случаях, когда бизнес уже вырос из старого интернет магазина, который без свистелок и перделок (хорошего юзабилити и функционала) дальше расти не может, при этом с учетом новых требований по функционалу нужно все писать с нуля.

[Viktor Vsk]

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

Так же, почитайте, что Макконел думает о дебаге и профайлинге. И как часто, по его словам, программисты ищут "узкое место" совсем не там, где оно на самом деле есть.

[Viktor Vsk]

Ну а по факту вопроса "интересно на будущее" - резюмируем:
1. Такие случаи крайне редки
2. Факторов, различающие "такие случаи" - огромное множество, которое постоянно новое и схожа будет только поверхность задачи
3. Как следствие - универсального алгоритма нет, т.к. куда проще\дешевле\надежнее решать эту задачу в конкретном случае уже на месте.