logo
logo

Форум Размер файла

создать новую тему раскрыть все
Размер файла Ko$tya 08/03/2004 19:14 #написать ответ
После каждого сохранения сильно увеличивается размер файла, при этом я не создаю новые операции, а только редактирую уже существующие.
Вот вся история:
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: Увеличение происходит за счёт того, что в файле есть неиспользуемое пространство. Оно нужно для устойчивости файла, который не должен потерять данные даже если компьютер выключился (например, отключилось электричество) в момент записи данных.
 
Видимо, я не совсем аккуратно отработал с организацией файла, он растёт именно за счёт этого неиспользуемого пространства.
 
Страшного в этом ничего нет, только действительно напрягает, что размер растёт. И я обещаю поправить эту ситуацию.
провёл ещё один эксперимент Ko$tya 08/03/2004 21:03 #написать ответ
Создал новую базу, сохранил.
Размер - 53КБ.
После каждого открытия и сохранения размер файла увеличивается на 51КБ.
 
Dervish: Спасибо, буду исправлять.
8) Serge Vesnin 12/03/2004 22:35 #написать ответ
2Гб.. 3Гб.. как это знакомо.. *)) и со временем она все больше и больше...
Очень бы хотелось, чтобы автор напервоочередно занялся оптимизацией файла базы.. Постоянно гоняю базу по почте.. Она, конечно, жмется, но не на столько, чтобы мои барышни не вопили каждый вечер, когда пересылают мне базу, что она "так долго таак доолго отпраавляяяетсяя" *)
 
"Все будет хорошо, я это знаюю..."
 
Скат.
 
Dervish: Сергей, не преувеличивайте: ваша база даже одного гигабайта не достигла.
 
Оптимизацией базы? Если вы считаете, что даже после сжатия она всё равно слишком велика, это означает, что мне нужно просто полностью переделать формат файла.
 
Можете привести цифры по размеру вашего файла (после сжатия) в сравнении с первой версией?
Пример Роман 13/03/2004 12:32 #написать ответ
У меня размер базы версии 1.4 - 460 Кб.
После сжатия 159 кб.(34%).
 
Та же база в версии 2.0 (билд18 - 1278 Кб. После сжатия - 1120Кб (87%).
 
Dervish: Роман, имелось в виду немного другое сжатие.
 
Попробуйте сделать открыть базу второу версии в программе и записать её на новое место, с новым названием (SaveAs - "Сохранить как..."). Вы увидите, что файл второй версии существенно уменьшится в объёме.
размер Serg 15/03/2004 12:11 #написать ответ
да, факт, если просто открывать и сохранять базу она увеличивается ~50Кб, крайне не приятный факт. я бы даже сказал критический...
 
Dervish: Будет исправлено.
Cжатие Роман 16/03/2004 14:13 #написать ответ
Я имел ввиду архивирование Zip-ом.
 
  Размер файла второй версии у меня уже после "Save as" такой.
  (Агентов-462,Валют-3,Операций-3243,Статей-75,Строк символов-1818, Счетов-19)
 
Dervish: Если ZIP хорошо будет сжимать зашифрованный файл, мне кажется, что это будет говорить о плохом качестве шифрования. Впрочем, я не специалист в шифровании и мог сказать чушь, извините, если что...
Уменьшение размера Сергей Битюцкий 16/03/2004 10:06 #написать ответ
Столкнулся с этой же проблемой. Вёл базу с 01.03.04, т.е. всего 3 недели, а размер уже больше 2Мб :-(
Однако, когда выполнил сохранение через "Сохранить как", то размер базы схлопнулся до 94кб :-)
Так что проблема как-то, но решается. Хотя и криво...
 
Dervish: Это особенность кода, собственно, так и планировалось. Если я исправлю ошибку с ростом базы на 50 килобайт (если ничего не изменялось), то база всё равно будет иметь несколько больший размер, чем нужно просто для хранения. И "лечиться" это будет через SaveAs. Могу сделать отдельный пункт с меню "Сжать базу данных".
Я за Дим(м) 16/03/2004 18:06 #написать ответ
Поддерживаю идею с отдельным пунктом меню.
А еще можно подумать над галочкой в настройках: "Оптимизировать базу при сохранении"
 
.. А потом уж и над: "Не использовать неоптимальный формат базы"
 
Dervish: ... и "не использовать базу данных"....
размер Serg 17/03/2004 06:15 #написать ответ
а ещё лучше просто при очередном сохранении изменений в базе проходить этап кода "сохранить как..." чтобы размер не рос на 50кб.
 
Dervish: Рост в 50 килобайт, это просто ошибка. Она должна быть (и будет) исправлена, тут не нужно изобретать велосипед.
Засомневался я,... Dervish 17/03/2004 14:14 #написать ответ
а правильно ли я сделал.
 
В общем, давайте я поясню, почему именно возникает необходимость в сжатии базы данных, почему файл имеет избыточный размер. Вполне возможно, что тут я перестарался и, возможно, что это стоит изменить.
 
Сейчас в базе фактически, находится две копии данных. Одна копия - актуальная, вторая - предыдущая, запасная.
 
Когда пользователь нажимает Ctrl+S, программа начинает записывать данные в файл. Но пишет данные поверх запасной копии, не трогая актуальную. Если места в запасной копии недостаточно (объём данных возрос), то в сам файл добавляется новое пространство.
 
И только после того, как новая версия данных сохранена, только тогда программа переустанавливает в файле один единственный указатель.
 
Зачем это было сделано? Очень просто: в любой момент времени файл актуален. И, фактически, крах файла может случиться только если питание компьютера пропадёт в момент переустановки указателя. А это очень маловероятно.
 
И тут же из такого подхода следует минус: файл больше нужного размера.
 
Ещё одно замечание: если вы во время сеанса изменили всего одну операцию, на новое место будут записываться не все операции, а только одна, вернее, только та страница файла, на которой находилась эта операция. Поэтому не нужно думать, что файл всегда в два раза больше нужного. Хотя, на практике, при активной работе такое тоже может произойти.
 
Как вы считаете будет лучше: оставить как есть (исправив ошибку с 50 килобайтами) или сделать так, чтобы всякий раз программа полностью переписывала файл и не обращать внимание на возможный риск потери данных (при отключении питания компьютера)?
ИМХО от потери данных в случае крэша Explorer 17/03/2004 16:01 #написать ответ
спасает полный бэкап, если мы говорим о потере данных текущего сеанса - имхо не существенно
 
Dervish: Да, если backup включен. А если нет? Сказать пользователю: "Нужно было настраивать backup, это твои проблемы"? Будет ли это хорошо?
Бэк Ап и все, все, все... Serge Vesnin 18/03/2004 12:32 #написать ответ
в 1.4 был именно бэк-ап.. и его вполне хватало... не уверен, что у 70% пользователей регулярно случаются проблемы с энергопитанием и потерей данных.
 
Dervish: Логично. Осталось понять, чего же это меня так занесло на повороте?
Есть еще вариант Дим(м) 17/03/2004 17:38 #написать ответ
При сохранении можно писать данные в отдельный временный файл. А потом просто заменять им исходный.
 
Dervish: Да, только нужно не забыть сделать замену так, чтобы никакой другой процесс не вклинился и не завладел файлом. А это непросто.
А если подумать... Дим(м) 17/03/2004 23:20 #написать ответ
С другой стороны, если подумать, то чем мы рискуем, если откажемся от настолько защищенного сохранения?
Данными, введенными пользователем во время последней сессии работы с программой?
Ну так пусть сохраняются почаще.
А еще можно автосохранение сделать и интервал подобрать не очень большой...
 
В данном конкретном случае, я думаю, будет не сильно критично, что база будет автоматически сохраняться в промежуточных состояниях. А уж если нужно всерьез иметь возможность откатиться к исходному состоянию, то надо пользоваться резервным копированием. Благо оно в программе есть с самого начала.
 
Dervish: Значит, вы считаете, что можно пожертвовать столь высокой защищённостью ради уменьшения объёма файлов? Я правильно понял?
Для меня большой разницы нет Дим(м) 18/03/2004 22:01 #написать ответ
Честно говоря, лично меня оба варианта почти одинаково устраивают. Базу я с собой таскаю не часто - и потому будет она 1 мегабайт или 2 - не имеет значения (разве только из неприязни к гигантомании Проблем с питанием вов ремя работы с предыдущей версией я на свою голову так ине поймал.
 
Просто я попытался посмотреть на это с другой стороны.
 
Но предпочтение я, пожалуй, все же отдам маленькой базе - чтобы "с дискеткой бегать".
 
Еще несколько напрягает то, что база постоянно распухает. Даже если я удалил из нее несколько десятков операций, она становится больше! Но с этим тоже можно смириться, если не поглядывать на размер базы после каждого чиха.
 
Похожая ситуация, кстати, с базами WinOrganizer. И там это тоже лечится через "Сохранить как" или "Оптимизировать базу".
 
А еще немного странно, что базы старой и новой версии так сильно отличаются в размерах. Далеко ведь не в два раза! И при этом в старом формате еще не было никакой компресии. А в новом, похоже, есть - по крайней мере, строчки по F3 не разглядишь. (или это шифрование без предварительного сжатия?)
Неужели структура базы/формат хранимых данных стали настолько сложными, что для сохранения требуется в несколько раз больше места? И это еще при использовании сжатия!
 
Dervish: "Так сильно отличаются в размерах" по тривиальной причине: если при каждом сохранении ошибочно добавлять по 50 килобайт, так может и диска не хватить. Так что, удивляться не следует.
 
Мнение понятно. Спасибо.
... кстати, о шифровании SKY 18/03/2004 23:22 #написать ответ
Действительно, файл практически не жмется архиваторами, да оно и понятно, раз есть шифрование. Но может можно несколько модифицировать процедуру шифрования таким образом, чтобы данные сначала сжимались, потом шифровались, а потом уж записывались? Понятное дело, будет чуть медленнее, но при нынешних процессорах это вроде не проблема.
 
Dervish: Если я изменю формат файла, то с шифрованием нужно будет отдельно разбираться и думать. Возможно, всё совсем придётся переделывать.
Мое ХО - вариант с файлом Alex 17/03/2004 23:30 #написать ответ
Я за полный Бэкап ибо, психологически у пользователя никогда нет уверенности в том, что такое "умное восстановление" восстановило все правильно. Мы уже перемалывали как-то эту тему. Это не Ворд  - тут деньги считают. А тестировать предложенный механизм путем набиения множества записей ручками и выдергиванием шнурка из розетки с последующей проверкой восстановленного - найдется мало желающих. А без тестирования у автора так никогда и не появится релиза
 
Хотя с другой стороны я даже больше за то чтоб сразу записи в базу писать. Есть такая прога PalmDesktop я в нее телефоны часто пишу на компутере, дык вот первая версия этой проги писала напрямую в БД на винт, а версия 4.01, которую сейчас пользую требует Save жать, но это я понял только после того как потерял не один десяток телефонов втечение года.
 
Резюме: писать сразу в БД + бэкап ручками/в директорном режиме/полностью в автоматическом режиме.
 
UnDo - Suxx для Cash 2. Нажал случайно неско раз и потом вспоминай чего постиралось
 
Dervish: Мнение про базу данных понятно.
 
Очень интересно мнение про то, что undo не нужно для Cash и его следует убрать. Интересно, какие будут ещё мнения на эту тему?
Про UnDo Ed 18/03/2004 10:21 #написать ответ
Мне тоже кажется излишним. Причем не только из-за неуверенности в содержании отката. Когда есть возможность вернуть, всегда становишься менее внимательным. А тут, как правильно замечено, все-таки денежки...
 
Dervish: Как-то раз мне понадобилось в базе данных первой версии сделать кое-какие манипуляции с данными. Те же самые операции нужно было иначе разнести по статьям, агентам и проектам. Честно скажу: я сам себя проклинал, когда ручками правил даже десяток-другой операций, устанавливая в них одну и ту же статью. Надо было, конечно, Excel-ем, но что-то сначала не подумал, а потом уже было просто жалко потраченных усилий.
 
В общем, мне кажется, что одновременная правка нескольких операций нужна далеко не всегда, но когда она понадобится, то без неё будет очень грустно. В общем, она должна быть в программе.
 
А если есть одновременная правка нескольких объектов, то следом вытекает желание сделать undo и redo. Так что, я вряд ли буду убирать из программы функциональность undo/redo.
 
Впрочем, никто не заставляет этим пользоваться.
Про UnDo и размер файла Роман 18/03/2004 11:00 #написать ответ
Мне кажется очень востребованным. Например: Вторая версия дает возможность изменять сразу несколько операций. Если при этом сделать ошибку - то вернуть все очень не просто. В старой версии я в рабочую базу импортировал данные, ошибся с названием счета и ... Если б не бекап...
С другой стороны, если кому-то это ни к чему пусть этим пунктом меню не пользуется.
 
Что касается размера файла та я за меньший размер, за автосохранение, и сохранение при сворачивании. Все конечно опционально.
 
P.S. Может кто-то посчитает какая вероятность что вырубится питание во время нажатия Ctrl-s.
 
Dervish: А если при автосохранении будет показываться окошко с прогресс-баром (точно таким же, как и сейчас), это ничего? Не пугает?
Про UnDo и размер файла Oleg 18/03/2004 12:50 #написать ответ
Полностью поддерживаю Романа про необходимость поддержки undo.
 
А насчет размера файла и того, что он не сжимается zip-ом, то никто не мешает отключить шифрование файла, в результате чего он очень хорошо сожмется. А поддержку "умного" восстановления лучше оставить опциональной, чтобы пользователь мог сам решить, что ему важнее - размер или содержимое.
 
Dervish: Ох, не хотелось бы мне отключать шифрование...
 
Не совсем понял про "умное" восстановление. Вы имели в виду алгоритмы, которые будут пытаться восстановить испорченную базу? Если да, то этим мне совсем не хотелось бы заниматься: никогда не верил, что можно сделать эффективным такой алгоритм.
Про шифрование и восстановление Oleg 19/03/2004 15:01 #написать ответ
Я не хотел совсем отключать шифрование. Я имел в виду, что если база в данный момент без пароля, то она не должна шифроваться. С паролем, конечно же, должна.
 
А под "умным" восстановлением я имел в виду то, что реализовано сейчас. Например, если пользователь отключил дублирование данных при записи, то новые записи пусть пишутся поверх старых, и указатель на последние актуальные данные не используется.
 
Dervish: А мне, честно говоря, хочется универсальности. И не хочется делать ветвление: есть пароль - шифруем, а если нет - не шифруем. Подумаю, может быть найдётся какой-нить способ...
Про UnDo и размер файла Vladimir 18/03/2004 18:57 #написать ответ
Поддерживаю Романа:
Что касается размера файла та я за меньший размер, за автосохранение, и сохранение при сворачивании. Все конечно опционально.
 
Dervish: ok, мнение понятно.
Может, его лучше в статус, этот прОгрес :) Дим(м) 18/03/2004 22:05 #написать ответ
.. чтобы не мелькало что-от непонятное время от времени перед глазами, а мирно выводилось в статусной строке: "Автосохранение: 40% [][][]"
Хотя да, нету ведь общей, глобальной статусной строки...
 
Dervish: Сделать общую статусную строку только для прогресса сохранения?
Почему только для сохранения? Дим(м) 24/03/2004 22:16 #написать ответ
Ну почему же только для сохранения?
Мало ли что в этой статусной строке можно показывать. Например, для страниц операций там будут еще и поля теперешние.
Для других страниц - тоже какая-нибудь статистическая информация: кол-во операций в базе по выбранной статье/валюте/счету, балансы, бюджет. Да мало ли что.
 
Кроме того, можно и другие длительные операции там же "прогрессировать". Какой-нть пересчет остатков или еще что.
 
В экселе, например, который здесь часто приводится в качестве примера, именно в общей статусной строке выводится прогресс сохранения.
 
Таково мое скромное мнение.
 
Dervish: Прежде всего, очень хочу сделать так, чтобы других длительно выполняющихся операций кроме чтения/записи файла просто не было. Думаю, это возможно.
 
Очень не хочется придумывать, что именно разместить на общем статус-баре, это похоже на высасывание из пальца. Либо смиряться, что в большинстве закладок стаус-бар будет пуст (например, в отчётах), либо оставить всё как есть.
UnDo - suxx! Alex 18/03/2004 15:11 #написать ответ
Dervish> Очень интересно мнение про то, что undo не нужно для Cash и его следует убрать.
 
Хмм...  я не говорил, что не нужно и тем более следует убрать, просто выразил мнение, что UnDo в _финансовой_ программе нонсенс. И я скорее всего пользоваться им никогда не буду и другим не буду рекомендовать...
 
Dervish: ок, я, видимо неправильно понял.
Redo Artem Fedorov 18/03/2004 16:03 #написать ответ
А redo не спасает?
 
Dervish:
на слабо... Explorer 18/03/2004 17:38 #написать ответ
а что если просто Do! типа как Go! и все само делается...
 
вот кайфно было-б
 
Dervish:
Еще лучше Artem Fedorov 18/03/2004 18:08 #написать ответ
Лучше сперва сделать кнопку "Make money"!
А добавить кнопку "Do" можно уже потом (в следующем релизе).
 
Dervish: Эх, ну что же вы всё о деньгах да о деньгах?..
5 баллов Explorer 18/03/2004 20:11 #написать ответ
а я не допер...
 
элементарная задача на оптимизацию