В AppData действительно хранится служебная база данных программы, без неё программа работала бы очень медленно. Можно воспринимать её просто как кэш данных. Все действительно важные данные при этом сохраняются в архив, как верно заметили выше - в метаданные, в ini и досье. Это единственно правильный подход, пользователь должен быть собственником своих данных, программа не имеет права прятать от него же его данные, хотя многие корпорации поступают именно так, чтобы искусственно привязать пользователя к себе. При этом ini и досье - проприетарные форматы, так что есть еще куда стремиться в плане открытости. Но это не от хорошей жизни, к сожалению нет альтернатив, пришлось изобретать свои форматы данных, так как существующие просто не подходят для хранения всех нужных данных.
Тем не менее, есть часть вторичных дынных, которая важна для комфортной работы пользователя, но при этом не является напрямую полезной информацией для архива, может храниться только во внутренней базе данных и больше нигде. К такой можно отнести список отрицательных примеров лиц для персоны. Согласитесь, писать в метаданные каждой фотографии кроме имени самого человека еще и список других имен, кем этот человек не является - было бы довольно странной идеей. Людям, просматривающим свой фотоархив данная информация не нужна совсем, она полезна только программе самой. Благо эти данные не являются критичными, их потеря - кратковременное неудобство, они быстро восстанавливаются путем нескольких отказов в интерфейсе.
Эти вторичные данные, плюс сам факт того, что кэш восстанавливаться может от нескольких часов до суток, в целом делают внутреннюю базу данных важным ресурсом, о безопасности которого нужно заботиться. В целом, это задача СУБД - обеспечение целостности данных. Однако, опыт показывает, что СУБД realm, которая используется в Tonfotos, всё-таки не обеспечивает 100% надежности, и при каких-то обстоятельствах может повреждать БД. Честно говоря, у меня нет подтверждённой статистики, является ли данный уровень числа сбоев статистически нормальным, или это свидетельствует о том, что с realm всё-таки есть проблемы. Субъективно кажется, что всё-таки с ней что-то не так, но это может просто так “ошибкой выжившего”, так как я общаюсь в основном с теми, у кого проблема, а те десятки тысяч, у кого всё ОК, они просто никогда не пишут. Возможно, какой-нибудь SQLite давал бы меньше сбоев, а может и нет. Достоверных исследований я не знаю. Поэтому, до сих пор у меня нет уверенности, что очень дорогостоящий проект по переписыванию на другую СУБД даст хоть какой-то положительный эффект.
В изначальном сообщении было предложение о автоматическом обслуживании БД. Идея действительно интересная и заслуживает изучения. На самом деле, какое-то обслуживание уже сейчас есть, но оно делается не по расписанию, а по мере того, как в базе накапливаются пусты фрагменты. Программа при запуске делает дефрагментацию. а потом заменяет базу на дефрагментированию. Это сделано, чтобы избежать распухания и торможения БД. Однако, нет достоверных данных о том, влияет ли подобная дефрагментация на вероятность сбоев в будущем или нет. Это тема для отдельного исследования. Однако, я пока даже не представляют с какой стороны подойти к данному исследованию, потому что до сих пор не известен механизм, который приводит к сбою данных, а значит я не могу вызвать его искусственно. А как тестировать исправление проблемы, если ты не очень-то можешь воспроизвести проблему - я не очень понимаю.
