Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Составной файл

Страницы: 1 2 >
Xerx © (2004-06-24 04:41:00)
Привет всем!
Вот появилась тут проблемка: нужно хранить кучу файлов в одном файле! Необходима обильная работа с внутренними файлами! Объясните как, либо укажите ссылку. Особо интересует УДАЛЕНИЕ файлов, с остальным все более-менее понятно.

Asinus (2004-07-12 07:15:00) [1]

> ЖЕЛАТЕЛЬНО БЕЗ VCL!!!

Тогда имеет смысл обратить внимание на Structured Storages. У А.Коншина есть удобная библиотека классов-оберток (не компоненты, исходники) вокруг API ф-й.
http://home.earthlink.net/~akonshin/delphi_ru.htm

Xerx (2004-07-12 04:20:00) [2]
>Amoeba
>Во-первых, не все так плохо - бесплатная версия полнофункциональная ...

Действительно, удобно! Но ничего не выбрасывает! И это по прежнему компонент, который в DLL занимает 389 Кб. Конечно, терпимо, но ЖЕЛАТЕЛЬНО БЕЗ VCL!!!

Fay (2004-07-10 05:07:00) [3]
2Xerx © (02.07.04 04:02) [20]
Можно хранить всё как связный список.

Xerx (2004-07-10 04:09:00) [4]
И правда, проще всего самому ручками все сделать.

Serginio666 (2004-07-02 17:23:00) [5]
Посмотри http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019
там пример хранения разных данных в том числе и блоб.
Причем размер блоба можешь настрооить сам

Amoeba (2004-07-02 14:35:00) [6]
Во-первых, не все так плохо - бесплатная версия полнофункциональная (сам использовал), только выбрасывается т.н. NagScreen при запуске программы. Но можно скачать на халяву с китайского варезного сайта (там можно найти много чего!) нормальную с исходниками:
http://www2.0zones.com:808/SoftDown.asp?ID=10612
Сайт доступен со второй половины дня по московскому времени.
Только Hepl придется брать от бесплатной с сайта AidAim.
Так что нет необходимости тратить гроши.

wicked (2004-07-02 14:04:00) [7]
> Amoeba [21]
прежде чем так навязчиво советовать его, следовало бы заглянуть сюда - http://www.aidaim.com/order/purchase.php#SFS
не думаю, что кто-то захочет отдавать 95 - 195 уёв...

Amoeba (2004-07-02 13:25:00) [8]
Single File System от AidAim
http://www.aidaim.com/products/delphi.php#sfs
Использование предельно просто и прозрачно. Это готовое и выполенное на профессиональном уровне решение твоей задачи. Стоит ли изобретать велосипед? Не факт, что колеса у него получатся достаточно круглыми.

Xerx (2004-07-02 04:02:00) [9]
> При использовании 'фата' нао хранить в начале файла таблицу - где начинается и где заканчивается каждый файл.

На мой взгляд гораздо удобнее хранить таблицу в КОНЦЕ файла. Представь ситуацию, когда нужно ДОБАВИТЬ новый файл. Таблица разростается и нужно перелопачивать ВЕСЬ ФАЙЛ ЗАНОВО! А если таблица в конце, то сохраняю новый файл поверх нее (ну и далее), и в конце дописываю новую таблицу!

Это моя реализация этой темы. Ничего лучше, чем натисать свое я не нашел.

TUser (2004-06-30 13:47:00) [10]

> А может все же стоит попробовать

Безусловно. Написание своей собственной файловой системы - не самая простая задача. Не ось, коненчо, но все-таки :) Если есть готовые решения, лучше использовать их.

Amoeba (2004-06-30 13:04:00) [11]
А может все же стоит попробовать: Single File System от AidAim
http://www.aidaim.com/products/delphi.php#sfs

Это не компонент, а 2 класса - потомка TObject

TUser (2004-06-30 11:44:00) [12]

> А нельзя ли поподробнее...

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

y-soft (2004-06-30 08:08:00) [13]
>Xerx © (30.06.04 04:18) [14]

А нельзя ли поподробнее по СУБД?

Например можно использовать таблицу такой структуры (только принцип - детали могут различаться):

CREATE TABLE FILE_STORAGE ( ID INTEGER NOT NULL, /*Уник. идент. файла*/ FILE_NAME VARCHAR(260) NOT NULL, /*Имя файла*/ PARENT INTEGER, /*Уник. идент. родительской директории*/ ATTRIBUTES INTEGER, /*Атрибуты файла*/ FILE_AGE TIMESTAMP, /*Дата создания файла*/ DATA BLOB SUBTYPE 0, /*Непосредственно данные*/ PRIMARY KEY (ID)); ALTER TABLE FILE_STORAGE ADD FOREGN KEY (PARENT) REFERENCES FILE_STORAGE ON UPDATE CASCADE ON DELETE CASCADE ;

При необходимости можно добавить и другие поля (дата последнего изменения, комментарии и пр.)

Поле FILE_NAMEлучше проиндексировать, но лучше вообще создать уникальный индекс по связке (PARENT, FILE_NAME)(чтобы обеспечить уникальность имен файлов в директории)

Для корневой директории поле PARENTравно NULL

С помощью SQL элементарно реализуются аналоги команд Dir, Deltree, Delete и т.д.

Можно организовать структуру БД и иначе - на http://ibase.ru, помнится, была статья по хранению древовидных структур

IMHO главные достоинства такого подхода: автоматически отслеживается целостность ссылок, легко решаются проблемы конфликтов совместного доступа и просто делается дефрагментация...

Xerx (2004-06-30 04:20:00) [14]
>TUser
>Если свлаить все в один файл ручками, то надо будет создать свою >таблицу наподобии фата, где хранить инфу о файлах. При удалении >первоначально старать из таблицы, переодически реструктурировать.
>Можно организовать в виде страниц/сегментом. При удалении память >реструктурировать не надо.

А нельзя ли поподробнее...

Xerx (2004-06-30 04:18:00) [15]
Смотрел я Storage, так там в примере больно часто ошибки вылезают. И проблемы с сохранением русского текста. Так что я пока отдам на хранение Storage свою самую нелюбимую книгу на французском - понятней не станет, а только в размере уменьшится! В общем, что-то не то.
Насчет XMl - ни в какие рамки: у меня большинство файлов будут бинарными (~95%).
Оперу я гляну...
А нельзя ли поподробнее по СУБД?

TUser (2004-06-28 09:22:00) [16]
Если свлаить все в один файл ручками, то надо будет создать свою таблицу наподобии фата, где хранить инфу о файлах. При удалении первоначально старать из таблицы, переодически реструктурировать.

Можно организовать в виде страниц/сегментом. При удалении память реструктурировать не надо.

X-Men (2004-06-28 08:54:00) [17]
Можно ещё сделать по принципу кэша Оперы. Правдо всё придётся писать руками.
PS SDK на их сайте(поиском)

y-soft (2004-06-28 08:48:00) [18]
>Amoeba © (24.06.04 13:23) [5]

Лучшее (и единственно правильное) решение задачи - структурированные хранилища.

Насчет этого высказывания можно очень и очень поспорить. У структурированных хранилищ есть и недостатки:

1. Склонность к фрагментированию
2. Неэкономное использование дискового пространства при хранении маленьких "файлов" (под каждый поток выделяется не менее 4 kb, даже если записывается всего 1 байт)
3. Довольно низкая скорость доступа
4. Функции по сортировке и фильтрованию придется реализовывать самостоятельно
5. формат поддерживается только в Windows

Можно subj реализовать и иными способами:

1. Хранить все в однофайловой базе данных

Достоинства: высокая скорость доступа в современных СУБД, возможность выполнения запросов по любым критериям

Недостатки: должна быть установлена эта самая СУБД

2. Использовать XML

Достоинства: поддержка встроена в современные ОС, возможно выполнять фильтрацию и сортировку, межплатформенная совместимость

Недостатки: XML по своей сути текстовый формат - придется озаботиться о конвертации двоичных данных. По этой же причине и использование дискового пространства неоптимально

3. Написать собственную альтернативу :)

Xerx (2004-06-28 04:29:00) [19]
Ну спасибо, на день чтения!!!
А компоненты не пойдут, я пишу без VCL. Но всё равно спасибО!

Xerx (2004-06-28 04:17:00) [20]
Ну спасибо, на день чтения!!!
А компоненты не пойдут, я пишу без VCL. Но всё равно спасибО!

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »