создать новую тему раскрыть все
После каждого сохранения сильно увеличивается размер файла, при этом я не создаю новые операции, а только редактирую уже существующие.
Вот вся история:
28.02 - загрузил базу из Cash 1.4 (412КБ) в AbilityCash сохранил в новом формате - получил файл размером 1,35МБ.
04.03 - 1,65МБ
07.03 - 2,00МБ
08.03 14:04 - 2,62МБ
08.03 23:30 - 2,93МБ
 
Провёл эксперимент: открыл файл, ничего не изменял, сохранил и вышел.
Теперь размер файла 2,98МБ
Ещё раз проделал тоже самое - теперь размер файла - 3,03МБ.
Почему так?
 
Dervish: Увеличение происходит за счёт того, что в файле есть неиспользуемое пространство. Оно нужно для устойчивости файла, который не должен потерять данные даже если компьютер выключился (например, отключилось электричество) в момент записи данных.
 
Видимо, я не совсем аккуратно отработал с организацией файла, он растёт именно за счёт этого неиспользуемого пространства.
 
Страшного в этом ничего нет, только действительно напрягает, что размер растёт. И я обещаю поправить эту ситуацию.
Создал новую базу, сохранил.
Размер - 53КБ.
После каждого открытия и сохранения размер файла увеличивается на 51КБ.
 
Dervish: Спасибо, буду исправлять.
2Гб.. 3Гб.. как это знакомо.. *)) и со временем она все больше и больше...
Очень бы хотелось, чтобы автор напервоочередно занялся оптимизацией файла базы.. Постоянно гоняю базу по почте.. Она, конечно, жмется, но не на столько, чтобы мои барышни не вопили каждый вечер, когда пересылают мне базу, что она "так долго таак доолго отпраавляяяетсяя" *)
 
"Все будет хорошо, я это знаюю..."
 
Скат.
 
Dervish: Сергей, не преувеличивайте: ваша база даже одного гигабайта не достигла. Well
 
Оптимизацией базы? Если вы считаете, что даже после сжатия она всё равно слишком велика, это означает, что мне нужно просто полностью переделать формат файла.
 
Можете привести цифры по размеру вашего файла (после сжатия) в сравнении с первой версией?
У меня размер базы версии 1.4 - 460 Кб.
После сжатия 159 кб.(34%).
 
Та же база в версии 2.0 (билд188) - 1278 Кб. После сжатия - 1120Кб (87%).
 
Dervish: Роман, имелось в виду немного другое сжатие.
 
Попробуйте сделать открыть базу второу версии в программе и записать её на новое место, с новым названием (SaveAs - "Сохранить как..."). Вы увидите, что файл второй версии существенно уменьшится в объёме.
да, факт, если просто открывать и сохранять базу она увеличивается ~50Кб, крайне не приятный факт. я бы даже сказал критический... Well
 
Dervish: Будет исправлено.
Я имел ввиду архивирование Zip-ом.
 
  Размер файла второй версии у меня уже после "Save as" такой.
  (Агентов-462,Валют-3,Операций-3243,Статей-75,Строк символов-1818, Счетов-19)
 
Dervish: Если ZIP хорошо будет сжимать зашифрованный файл, мне кажется, что это будет говорить о плохом качестве шифрования. Впрочем, я не специалист в шифровании и мог сказать чушь, извините, если что...
Столкнулся с этой же проблемой. Вёл базу с 01.03.04, т.е. всего 3 недели, а размер уже больше 2Мб :-(
Однако, когда выполнил сохранение через "Сохранить как", то размер базы схлопнулся до 94кб :-)
Так что проблема как-то, но решается. Хотя и криво...
 
Dervish: Это особенность кода, собственно, так и планировалось. Если я исправлю ошибку с ростом базы на 50 килобайт (если ничего не изменялось), то база всё равно будет иметь несколько больший размер, чем нужно просто для хранения. И "лечиться" это будет через SaveAs. Могу сделать отдельный пункт с меню "Сжать базу данных".
Поддерживаю идею с отдельным пунктом меню.
А еще можно подумать над галочкой в настройках: "Оптимизировать базу при сохранении" Well
 
.. А потом уж и над: "Не использовать неоптимальный формат базы" To wink
 
Dervish: ... и "не использовать базу данных".... Well
а ещё лучше просто при очередном сохранении изменений в базе проходить этап кода "сохранить как..." чтобы размер не рос на 50кб.
 
Dervish: Рост в 50 килобайт, это просто ошибка. Она должна быть (и будет) исправлена, тут не нужно изобретать велосипед.
а правильно ли я сделал.
 
В общем, давайте я поясню, почему именно возникает необходимость в сжатии базы данных, почему файл имеет избыточный размер. Вполне возможно, что тут я перестарался и, возможно, что это стоит изменить.
 
Сейчас в базе фактически, находится две копии данных. Одна копия - актуальная, вторая - предыдущая, запасная.
 
Когда пользователь нажимает Ctrl+S, программа начинает записывать данные в файл. Но пишет данные поверх запасной копии, не трогая актуальную. Если места в запасной копии недостаточно (объём данных возрос), то в сам файл добавляется новое пространство.
 
И только после того, как новая версия данных сохранена, только тогда программа переустанавливает в файле один единственный указатель.
 
Зачем это было сделано? Очень просто: в любой момент времени файл актуален. И, фактически, крах файла может случиться только если питание компьютера пропадёт в момент переустановки указателя. А это очень маловероятно.
 
И тут же из такого подхода следует минус: файл больше нужного размера.
 
Ещё одно замечание: если вы во время сеанса изменили всего одну операцию, на новое место будут записываться не все операции, а только одна, вернее, только та страница файла, на которой находилась эта операция. Поэтому не нужно думать, что файл всегда в два раза больше нужного. Хотя, на практике, при активной работе такое тоже может произойти.
 
Как вы считаете будет лучше: оставить как есть (исправив ошибку с 50 килобайтами) или сделать так, чтобы всякий раз программа полностью переписывала файл и не обращать внимание на возможный риск потери данных (при отключении питания компьютера)?
спасает полный бэкап, если мы говорим о потере данных текущего сеанса - имхо не существенно
 
Dervish: Да, если backup включен. А если нет? Сказать пользователю: "Нужно было настраивать backup, это твои проблемы"? Будет ли это хорошо?
в 1.4 был именно бэк-ап.. и его вполне хватало... не уверен, что у 70% пользователей регулярно случаются проблемы с энергопитанием и потерей данных. 8)
 
Dervish: Логично. Осталось понять, чего же это меня так занесло на повороте? To wink
При сохранении можно писать данные в отдельный временный файл. А потом просто заменять им исходный.
 
Dervish: Да, только нужно не забыть сделать замену так, чтобы никакой другой процесс не вклинился и не завладел файлом. А это непросто.
С другой стороны, если подумать, то чем мы рискуем, если откажемся от настолько защищенного сохранения?
Данными, введенными пользователем во время последней сессии работы с программой?
Ну так пусть сохраняются почаще. Well
А еще можно автосохранение сделать и интервал подобрать не очень большой...
 
В данном конкретном случае, я думаю, будет не сильно критично, что база будет автоматически сохраняться в промежуточных состояниях. А уж если нужно всерьез иметь возможность откатиться к исходному состоянию, то надо пользоваться резервным копированием. Благо оно в программе есть с самого начала. Well
 
Dervish: Значит, вы считаете, что можно пожертвовать столь высокой защищённостью ради уменьшения объёма файлов? Я правильно понял?
Честно говоря, лично меня оба варианта почти одинаково устраивают. Well Базу я с собой таскаю не часто - и потому будет она 1 мегабайт или 2 - не имеет значения (разве только из неприязни к гигантомании Well Проблем с питанием вов ремя работы с предыдущей версией я на свою голову так ине поймал.
 
Просто я попытался посмотреть на это с другой стороны. Well
 
Но предпочтение я, пожалуй, все же отдам маленькой базе - чтобы "с дискеткой бегать". Well
 
Еще несколько напрягает то, что база постоянно распухает. Даже если я удалил из нее несколько десятков операций, она становится больше! Но с этим тоже можно смириться, если не поглядывать на размер базы после каждого чиха. Well
 
Похожая ситуация, кстати, с базами WinOrganizer. И там это тоже лечится через "Сохранить как" или "Оптимизировать базу".
 
А еще немного странно, что базы старой и новой версии так сильно отличаются в размерах. Далеко ведь не в два раза! И при этом в старом формате еще не было никакой компресии. А в новом, похоже, есть - по крайней мере, строчки по F3 не разглядишь. Well (или это шифрование без предварительного сжатия?)
Неужели структура базы/формат хранимых данных стали настолько сложными, что для сохранения требуется в несколько раз больше места? И это еще при использовании сжатия!
 
Dervish: "Так сильно отличаются в размерах" по тривиальной причине: если при каждом сохранении ошибочно добавлять по 50 килобайт, так может и диска не хватить. Так что, удивляться не следует.
 
Мнение понятно. Спасибо.
Действительно, файл практически не жмется архиваторами, да оно и понятно, раз есть шифрование. Но может можно несколько модифицировать процедуру шифрования таким образом, чтобы данные сначала сжимались, потом шифровались, а потом уж записывались? Понятное дело, будет чуть медленнее, но при нынешних процессорах это вроде не проблема.
 
Dervish: Если я изменю формат файла, то с шифрованием нужно будет отдельно разбираться и думать. Возможно, всё совсем придётся переделывать.
Я за полный Бэкап ибо, психологически у пользователя никогда нет уверенности в том, что такое "умное восстановление" восстановило все правильно. Мы уже перемалывали как-то эту тему. Это не Ворд  - тут деньги считают. А тестировать предложенный механизм путем набиения множества записей ручками и выдергиванием шнурка из розетки с последующей проверкой восстановленного - найдется мало желающих. А без тестирования у автора так никогда и не появится релиза Not so
 
Хотя с другой стороны я даже больше за то чтоб сразу записи в базу писать. Есть такая прога PalmDesktop я в нее телефоны часто пишу на компутере, дык вот первая версия этой проги писала напрямую в БД на винт, а версия 4.01, которую сейчас пользую требует Save жать, но это я понял только после того как потерял не один десяток телефонов втечение года.
 
Резюме: писать сразу в БД + бэкап ручками/в директорном режиме/полностью в автоматическом режиме.
 
UnDo - Suxx для Cash 2. Нажал случайно неско раз и потом вспоминай чего постиралось Well
 
Dervish: Мнение про базу данных понятно.
 
Очень интересно мнение про то, что undo не нужно для Cash и его следует убрать. Интересно, какие будут ещё мнения на эту тему?
Мне тоже кажется излишним. Причем не только из-за неуверенности в содержании отката. Когда есть возможность вернуть, всегда становишься менее внимательным. А тут, как правильно замечено, все-таки денежки...
 
Dervish: Как-то раз мне понадобилось в базе данных первой версии сделать кое-какие манипуляции с данными. Те же самые операции нужно было иначе разнести по статьям, агентам и проектам. Честно скажу: я сам себя проклинал, когда ручками правил даже десяток-другой операций, устанавливая в них одну и ту же статью. Надо было, конечно, Excel-ем, но что-то сначала не подумал, а потом уже было просто жалко потраченных усилий.
 
В общем, мне кажется, что одновременная правка нескольких операций нужна далеко не всегда, но когда она понадобится, то без неё будет очень грустно. В общем, она должна быть в программе.
 
А если есть одновременная правка нескольких объектов, то следом вытекает желание сделать undo и redo. Так что, я вряд ли буду убирать из программы функциональность undo/redo.
 
Впрочем, никто не заставляет этим пользоваться. Well
Мне кажется очень востребованным. Например: Вторая версия дает возможность изменять сразу несколько операций. Если при этом сделать ошибку - то вернуть все очень не просто. В старой версии я в рабочую базу импортировал данные, ошибся с названием счета и ... Если б не бекап...
С другой стороны, если кому-то это ни к чему пусть этим пунктом меню не пользуется.
 
Что касается размера файла та я за меньший размер, за автосохранение, и сохранение при сворачивании. Все конечно опционально.
 
P.S. Может кто-то посчитает какая вероятность что вырубится питание во время нажатия Ctrl-s.
 
Dervish: А если при автосохранении будет показываться окошко с прогресс-баром (точно таким же, как и сейчас), это ничего? Не пугает?
Полностью поддерживаю Романа про необходимость поддержки undo.
 
А насчет размера файла и того, что он не сжимается zip-ом, то никто не мешает отключить шифрование файла, в результате чего он очень хорошо сожмется. А поддержку "умного" восстановления лучше оставить опциональной, чтобы пользователь мог сам решить, что ему важнее - размер или содержимое.
 
Dervish: Ох, не хотелось бы мне отключать шифрование...
 
Не совсем понял про "умное" восстановление. Вы имели в виду алгоритмы, которые будут пытаться восстановить испорченную базу? Если да, то этим мне совсем не хотелось бы заниматься: никогда не верил, что можно сделать эффективным такой алгоритм.
Я не хотел совсем отключать шифрование. Я имел в виду, что если база в данный момент без пароля, то она не должна шифроваться. С паролем, конечно же, должна.
 
А под "умным" восстановлением я имел в виду то, что реализовано сейчас. Например, если пользователь отключил дублирование данных при записи, то новые записи пусть пишутся поверх старых, и указатель на последние актуальные данные не используется.
 
Dervish: А мне, честно говоря, хочется универсальности. И не хочется делать ветвление: есть пароль - шифруем, а если нет - не шифруем. Подумаю, может быть найдётся какой-нить способ...
Поддерживаю Романа:
Что касается размера файла та я за меньший размер, за автосохранение, и сохранение при сворачивании. Все конечно опционально.
 
Dervish: ok, мнение понятно.
.. чтобы не мелькало что-от непонятное время от времени перед глазами, а мирно выводилось в статусной строке: "Автосохранение: 40% [][][]"
Хотя да, нету ведь общей, глобальной статусной строки... Not so
 
Dervish: Сделать общую статусную строку только для прогресса сохранения?
Ну почему же только для сохранения?
Мало ли что в этой статусной строке можно показывать. Например, для страниц операций там будут еще и поля теперешние.
Для других страниц - тоже какая-нибудь статистическая информация: кол-во операций в базе по выбранной статье/валюте/счету, балансы, бюджет. Да мало ли что.
 
Кроме того, можно и другие длительные операции там же "прогрессировать". Какой-нть пересчет остатков или еще что.
 
В экселе, например, который здесь часто приводится в качестве примера, именно в общей статусной строке выводится прогресс сохранения.
 
Таково мое скромное мнение. Well
 
Dervish: Прежде всего, очень хочу сделать так, чтобы других длительно выполняющихся операций кроме чтения/записи файла просто не было. Думаю, это возможно.
 
Очень не хочется придумывать, что именно разместить на общем статус-баре, это похоже на высасывание из пальца. Либо смиряться, что в большинстве закладок стаус-бар будет пуст (например, в отчётах), либо оставить всё как есть.
Dervish> Очень интересно мнение про то, что undo не нужно для Cash и его следует убрать.
 
Хмм...  я не говорил, что не нужно и тем более следует убрать, просто выразил мнение, что UnDo в _финансовой_ программе нонсенс. И я скорее всего пользоваться им никогда не буду и другим не буду рекомендовать...
 
Dervish: ок, я, видимо неправильно понял.
А redo не спасает?
 
Dervish: Well
а что если просто Do! типа как Go! и все само делается...
 
вот кайфно было-б
 
Dervish: Well
Лучше сперва сделать кнопку "Make money"!
А добавить кнопку "Do" можно уже потом (в следующем релизе).
 
Dervish: Эх, ну что же вы всё о деньгах да о деньгах?.. To wink
а я не допер...
 
элементарная задача на оптимизацию