jagev: ну на фрилансе найдите, кто сделает вам демо-сервер. вы себе же платите деньги? немного урежьте себе, дайте тому кто сделает вам единоразово по вашему ТЗ.
jagev: ну вообще чтобы реализовать такое надо чтобы язык поддерживал:
0. ООП - без него я хз как вообще жить
1. сокеты - соединение будет постоянным
2. многопоточность - без него никуда вообще
3. сборку мусора - ручная или автоматическая ваш выбор
4. событийную модель - можно и без нее закостылить, но с ней проще
Поэтому ищите человека с опытом, берите его в команду.
еще есть подход называется ReadModel + CQRS. На основе событий, сообщений.
Т.е. ваш кеш реализуется в виде слушателя сообщений на изменение данных. Репозиторий при изменении БД шлет событие в шину данных - слушатель обновляет себя в пямяти и отдает данные сайту.
Т.е. в БД мы пишем в одной системе - а читаем в другой. Разделяем нагрузку.
При этом число слушателей можно увеличить, сделать больше одного. Но писать данные может только одна система. Почитайте про CQRS - она может даже лучше зайдет вам. Но там много кода и работы. MemoryCache проще.
Михаил Плюснин: если у вас CRUD подход такой:
на Insert/Create делаете Add в кеш;
на Get/Read - делает Get - если устарели - делаете Get из БД - затем Add в кеш;
на Update делаете Set в кеш;
на Delete/Remove - делаете Remove в кеше.
Пользователи увидят новые данные сразу. Кеш нужен только чтобы не обращаться в БД лишний раз. А снижение нагрузки на БД выражается как раз в Expiration.
Еще есть момент - если у вас данные обновляются из другой системы - например Админки, командной строки или вообще напрямую в БД внесли данные - в этом случае - да, увидят информацию новую не сразу - а когда закончится Expiration.
выглядит здорово, на первый взгляд.
но. количество человек от 1 до 5. мне надо больше 15 человек рассчитать.
но в целом выглядит хорошо, с задачей справляется. попробовал разные кейсы на ней.
и еще надо помнить людей под номерами - было бы здорово их указать поименно, а не 1,2,3,4,5.
и блюда почему-то строго пиктограммой, без имени, тоже бы переименовать или указать имя.
странное приложение с точки зрения юзабилити.
Алексей Смирнов: Тогда вам надо задеплоить или выложить приложение на сервер/облако. И настроить там планировщик. НО переписывать на андройд, думая, что у вас телефон будет всегда включен, интернет там всегда будет, батарейка не сядет и т.д. - это неверный подход и путь.
StynuBlizz: понял. Ну хорошо, делайте рандом соль. Но все равно надо выделять микросервис, отдельную БД под это дело. И желательно на сервер отдельный.
Как говориться, не хранить яйца в одной корзине.
А сама БД сайта - будет хранить только хеш и uid пользователя.
uid, пароль и hash шлем в микросервис, он там находит соль, делает шифрование - сравнивает - отдает ответ.
StynuBlizz: у вас будет 1 000 000 пользователей - вы будете хранить 1 000 000 значений соли - зачем? где будете хранить? в БД ? ее украдут и пиши пропало.
Микросорвис станет узкозаточенным под ваш сайт - знающий 1 000 000 значений соли, а также связи с реальным человеком из БД. так не делают
