Как реализовать логику работы с БД для нестандартного решения?

Question

[movetz]

Хочу услышать мнение и идеи жителей тостера=))
О проекте:
Есть веб и мобильное приложение, на стороне веба пользователи (админы, менеджеры и т.п.) наполняют контент - текст файл и т.п., на стороне девайса - просмотр. Ничего не обычного.
О проблеме:
Все вроде бы ясно и понятно, но контент для должен быть доступным только после публикации, то есть мы редактируем контент в большой куче разделов, заливаем файлы, но на стороне девайса информация не меняется, потом нажимаем на кнопку сабмит и изменения становятся доступными.
Идеи :

1. Генерировать после публикации кеш - json файл со всеми данными. Вариант отличный, но как в этом случае организовать поиск.
2. Загружать данные в локалсторедж и потом их синхронизировать с БД. Надежность синхронизации вызывает сомнения.
3. При начале редактирования дублировать все данные в базе и для дубликатов создавать отдельную метку. Не плохо, но не хотелось бы делать много лишних движений.
4. Может быть что-то еще? Очень интересно было бы услышать варианты решения без использования SQL

Заранее большое спасибо!

Answer 1

[Viktor Vsk]

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

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

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

Comments

[movetz]

Виноват, хотел написать максимально коротко, получилось как всегда=)
Еще раз о проекте:
есть приложение для просмотра музыкальных исполнителей (концерты, альбомы, реклама). На стороне девайса реализован просмотр и поиск исполнителей (альбомов, концертов). На стороне веба - сервисы для всех данных и приложение для администрирования информации соответствующего исполнителя - общая информация, фото, заливка альбомов с аудио файлами и обложек альбомов и т.п.
Стек технологий:
PHP (Laravel) + MySQL, сервер Apache (может Nginx), на клиенте - Ember. Про мобильную часть ничего сказать не могу, предоставляем только сервисы.

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

Может быть есть уже готовые подходы к решению такой задачи?

Заранее большое спасибо))

Answer 2

[des1roer]

Ничего не обычного. пиши слитно