Почему хранение данных в Эксель занимают так много места ?

← →
Dmitriy O. © (2004-12-09 08:55) [0]

При заполнении ячеек вес книги Экселя растет с геометрической прогрессий. Для эксперемента я заполнил один лист экселя все ячейки текстом "FFFF" при этом вес его достиг 227 мб ! И он сожрал всю виртуальную память моего компа ! Также заметил что форматирование ячеек вроде тоже приводит к увеличению веса книги.
И при этом нам Микрософт пытается впарить его (Эксель) как типа средство чуть ли не для создания бух. программ и складов !
Кстати макросы тоже значительно увеличивают размер книги.
Т.е. по сути Эксель не пригоден для работы с каким либо более-менее значимым обьемом инфы.

← →
_maximus (2004-12-09 10:31) [1]

Про ихний Акцесс я вообще молчу!!!

← →
Val © (2004-12-09 10:34) [2]

У данных приложений есть своя ниша. В ней они выглядят ОЧЕНЬ достойно. Не стоит сравнивать их с промышленными SQL серверами, это некорректно и попросту глупо.

← →
TUser © (2004-12-09 10:34) [3]

А если попробовать ему сделать Save As? С Ёкселем не пробовал, а вот ворд точно пихает в свои файлы много лишней ерунды, файл растет если его много раз сохранить, но Save As позволяет ужать размер.

← →
DVM © (2004-12-09 10:45) [4]

> Т.е. по сути Эксель не пригоден для работы с каким либо
> более-менее значимым обьемом инфы.

Не пригоден. Для этого есть Access.

← →
Суслик © (2004-12-09 11:07) [5]

Разрешите выступить в качестве эксперта по способу хранения данных в excel.

Для хранения данных excel ипользует структурные хранилища. Формат хранения данных в файле является достаточно оптимальным. Достаточно сказать, что в приведенном примере строка ffff хранится один раз в записи sst (shared string table). Каждая ячека хранит только 2б идентификатора стиля и ссылку на данные. С стиле хранятся все параметры - границы, цвет, ссылка на шриф и пр. Стили могут использоваться несколькоими ячейками.
Более того, ексель имеет средства сжатия. Например, идущие подряд одинаковые ячейки заменяются одной с указанием начала и конца и пр. и пр.

Теперь о проблеме, обозначенно ДО.
Я не дебужил ексель (не умею), но у меня есть ощущение, что он работает в двух режимах:
1. Режим ввода нового документа. В этом случае все в памяти. Причем не очень оптимально.
2. Режим редактирования. В этом случае используются возможности структурных хранилищ. Я сам лично создавал документ большого размера (10 страниц, на каждой 65000 строки 255 столбцов). Ексель его легко открвает. Тогда как создать такой файл в среде - нереально (у меня на машине).

У екселя есть слабые места. Одно из них - неумение работать с большим количество объединений ячеек и ограниченное их количество. Если создать файл с 30000 объединений - у меня на машине он будет открываться 1 час. Тогда как тот же файл, но без объединений - 10 сек. Есть еще что-то, но я забыл уже - давно было.

ЗЫ. Речь шла про современный формат xls - biff8 и biff8x (они похожи).

← →
Суслик © (2004-12-09 11:16) [6]

> Т.е. по сути Эксель не пригоден для работы с каким либо
> более-менее значимым обьемом инфы.

С этим позволь не согласится. Именно для того, чтобы можно была "варить" большие объемы начиная с версии biff6 или biff7 файл ексель - это структурное хранилище (istorage и istream). Именно поэтому ексель вроде как должен поддреживать многопользовательскую работу над документом (работает ли, нет - не знаю, т.к. не пробовал). Естественно ексель не грузит все в в память.

← →
DiamondShark © (2004-12-09 11:23) [7]

> Для эксперемента я заполнил один лист экселя все ячейки
> текстом "FFFF" при этом вес его достиг 227 мб !

Т.е. 256 столбцов по 65536 строк.
256 * 65536 * 4(кол-во символов) * 2(размер юникод-символа) = 134217728 байт = 128 Мб
Иными словами, overhead составляет чуть меньше чем 2 раза.
Если учитывать, что лист экселя -- это не тупая матрица строк, а довольно сложная структура, то результат надо считать более чем удовлетворительным.

В качестве домашнегой задания можно рекомендовать подумать над структурой, реализующей хотябы минимум экселевской функциональности и со значительно меньшими (да хоть бы и такими же) накладными расходами.
Правда, будет несколько мешать торчащий в руках флаг...

> И при этом нам Микрософт пытается впарить его (Эксель) как
> типа средство чуть ли не для создания бух. программ и складов
> !

Это тебя обманули.

---
"Грусно, до чего ламерство окрепло." (ц)

← →
Суслик © (2004-12-09 11:26) [8]

кстати, если ДО удалось бы этот файл сохранить, уверен, что он занимал бы не более 1 мб на диске

← →
Суслик © (2004-12-09 11:38) [9]

> 256 * 65536 * 4(кол-во символов) * 2(размер юникод-символа) > = 134217728 байт = 128 Мб

Еще слова в защиту екселя...
Они строки хранят как в unicode, так и не unicode. Зависит от флажка в первом байте. Также длина может задаваться либо 1 либо 2 байта. Тоже в виде бита в первом байте. В случае ffff - был бы не unicode (вернее, точно ansi -проверил только что). В общем не такие они там дураки.

← →
TUser © (2004-12-09 12:03) [10]

> кстати, если ДО удалось бы этот файл сохранить, уверен,
> что он занимал бы не более 1 мб на диске

Нет. Тут Дима правду сказал. Действительно 227.

← →
Суслик © (2004-12-09 12:07) [11]

> [10] TUser © (09.12.04 12:03)

> Нет. Тут Дима правду сказал. Действительно 227.

не может быть. Хотя может. Скажу честно, что из интерфейса такое не проделывал никогда. Тогда возникает вопрос: зачем тогда разработан biff8? Повторяю - это очень оптимальный формат. Т.о. получается, что сам ексель не умеет оптимально сам же писать в свой формат? Ну может быть, хотя странно это как-то

← →
Dmitriy O. © (2004-12-09 12:14) [12]

> Суслик © (09.12.04 12:07) [11]

Так я сохранял этот файл на диск. И он действительно на диске занимал столькоже сколько и в виртуальной памяти 227 мегов.
Скорее всего действительно сам эксель не может сохранять их оптимально.

← →
Суслик © (2004-12-09 12:17) [13]

> [12] Dmitriy O. © (09.12.04 12:14)

Фиг его знает. Неоднократно замечал, когда он производил реструктуризацию данных.

У него есть таблица строк - sst. Каждая строковая ячейка реализуется записью (запись, это тип, длина, данные) - labelsst, которая ссылается на sst. По идее одна и таже строка может быть использована в разных ячейках.
Иногда замечал, что в sst лежат дубликаты. А потом - раз и пропали.

← →
Dmitriy O. © (2004-12-09 12:34) [14]

Одноко сводные таблицы могут сжиматься при сохранении.
Надо только сбросить Флажек в параметрах сводной таблицы "сохранять данные в месте с таблицей" И тогда Книга Эксель используящая сводные таблицы может похудеть более чем в два раза.

← →
DiamondShark © (2004-12-09 12:52) [15]

Что-то вы, ребята, напутали.

Запустил макрос, заполняющий весь лист (256х65536) строкой "FFFF".

Диспетчер задач показывает 137 Мб занятых процессом.

Размер файла после сохранения действительно 227 Мб.

Размер памяти процесса после сохранения файла уменьшился до 50 Мб

← →
Dmitriy O. © (2004-12-09 12:59) [16]

> DiamondShark © (09.12.04 12:52) [15]

Вообщето макрос чтобы заполнить весь лист Экселя однотипными данными не требуется. Надо только в первом Cells написать чтото
например FFFF потом Нажать на "Копировать" потом выделить весь лист (Щелкнуть на пустом квадратике в месте пересечения строк и столбцев - левый самый верхний и самый крайний) И нажать на "Вставить" правдо после этого комп подвиснет на пару тройку минут процессор будет занят на 99 % Но цель будет достигнута.

← →
Суслик © (2004-12-09 13:13) [17]

> [15] DiamondShark © (09.12.04 12:52)
> Что-то вы, ребята, напутали.

ничего я не напутал.
Да, действтиельно 227 мб.
Строка ffff хранится один раз - можешь поиском позыркать.
Все остальное это инофрмация о ячейках.
Не пойму, почему он не оптимизировал себя?
Обычно для одного ряда из одинакоых строки он пишет записть MultiLabelSST, здесь же 256 LabelSST.
В качестве доказательства своих слов ничего, кроме как изучать доку в openoffice.org предложить не могу. Свой браузер - это свой браузер. :))

> Суслик © (09.12.04 13:13) [17]

Да по-барабану как он в файле хранится.

Факт в том, что в памяти он с ним обращается весьма эффективно.
А это противоречит исходному утверждению, что "по сути Эксель не пригоден для работы с каким либо более-менее значимым обьемом инфы".

> Факт в том, что в памяти он с ним обращается весьма эффективно.

а я тебе говорю, что мог бы еще эффективней.
Я тебе могу создать такой же файл, но в 4 раза короче. Я этого делать только не буду - т.к. multilabelsst я тоже не делал, у меня только lablesst. Но это возможно.

> а вот ворд точно пихает в свои файлы много лишней ерунды,
> файл растет если его много раз сохранить,

Если в насторойках снята галочка, разрешающая "быстрое сохранение", то такого не наблюдается.

Если интересно - создал вчера ручками файл аналогичной функциональности - 4 мб.
Повторю, что сам ексель иногда себя успешно оптимизирует. Понять логику (когда он это делает, когда нет) я не могу.

Хотя, если честно - он не совсем такой же функциональности получился - у меня числа ffff хранятся. т.е. не строки (так быстрее было сделать). Нет времени смотреть можно ли такую оптимизацию и для строк провести. Может и нельзя.

> правдо после этого комп подвиснет на пару тройку минут процессор
> будет занят на 99 %

макрос пишется за 30 секунд, и работает за еще примерно столько же.

> TUser © (10.12.04 10:57) [23]

И того минута. Примерно столькоже сколько Вставка через буфер идет.
Но посчитайте ручной труд чтобы написать макрос надо надавить не на клавиши не менее 100 раз.
А чтобы вставить через буфер только-2 раза.
Лень это двигатель прогресса.

Почему хранение данных в Эксель занимают так много места ? Найти похожие ветки