Семаджик

> это нужно только для просмотра, понимаешь?
> для местного просмотра сохранённых записей.
Ага.
Кстати, это должно быть вместо имеющейся в Semagic-е истории записей, лазающей за сведениями на сервер, или дополнительно к ней?

> мне начхать на то, что там добавлено откуда-то.
Тебе начихивать просто — ты не автор Семаджика, и тебя, в случае неудачной реализации, пинать не будут.

> а уж пройтись этому просмотрщику (по команде пользователя) и проверить, какие записи появились или изменились и скачать их - это запросто сделать!
Ты очень оптимистичен.
Проходить по какому периоду? С начала существования ЖЖ? — это весьма долго; в указанном пользователем диапазоне? — а что, если он пишет настолько часто и разнообразно, что не помнит, какие диапазоны надо синхронизировать? Как предложишь обходить эти use-case-ы, чтобы пользователь ничего не потерял?
Появились/удалились — проверить ещё можно. А вот чтобы проверить, изменилась ли запись, её придётся скачать. Что ты там говорил про 4 мегабайта :) ?

> а если ты точно уверен, что пишешь только со своего одного Семаджика,
Достаточно мало распространённая ситуация.

> то эту кнопку и не тронешь.
Ага. Кнопку. А если ты забыл её нажать, а после чего полчаса искал одну свою старую запись, переформулируя запросы по-всякому и забыв, что её писал из интернет-кафешки, то… тебя ждут негативные эмоции. Которых программа вызывать не должна.

> и лопнула она как мыльный пузырь ;)
От того, что ты посчитал, что проблемы нет, она не исчезла. Она существует вне зависимости твоего мнения о ней.
Кстати, способ аргументирования «если не можешь опровергнуть — отвергни» хорошо описан в «Заметках о женской логике» Беклемишева.

---

Решение с кэшированием записей является частным случаем более общей проблемы проектирования. Как известно, при проектировании каждая сущность во избежании проблем должна храниться один и только один раз (например, когда ты пишешь программу, и в разных местах у тебя встречается один и тот же код, ты его обычно выносишь в новую функцию; когда при создании таблицы в базе данных ты замечаешь, скажем, что каждому значению одной колонки соответствует конкретное значение другой колонки, ты переводишь таблицу в нормальную форму более высокого порядка).
В случае, если одна и та же сущность дублируется в разных местах, начинаются проблемы: приходится учитывать ситуации, когда эти сущности выходят из состояния идентичности/эквивалентности, оценивать последствия этого и предотвращать это (например, если у тебя есть каталог с документами и бэкап этого каталога, то эти сущности с виду эквивалентны, но в любой момент могут разойтись — либо документы изменятся, либо бэкап попортится. И поэтому для поддержания идентичности бэкапы снимать приходится регулярно, а особо паранойидальные люди ещё и регулярно проверяют, не испортились ли хранящиеся у них бэкапы).
Поэтому наиболее простым стабильным состоянием хорошо спроектированной системы является такое, при котором каждая его индивидуальная и независимая сущность хранится отдельно, а все зависимые выводятся через определённо не зависимые. В то же время, иногда систему сознательно проектируют с дублированием сущностей: обычно это либо делается либо ради оптимизации каких-то пользовательских характеристик (например, производительности — посредством всевозможных кэшей), либо для увеличения надёжности (бэкапы; дублирование важных систем в критических областях использования, как, например, в авиации, на опасных производствах; RAID-массивы). Но такое решение, как уже понятно из написанного выше, заведомо существенно усложняет систему и вызывает необходимость во множестве дополнительных механизмов обеспечения целостности (идентичности копий) (в объёмах, зависящих от степени опасности последствий расхождения идентичности сущностей).