Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

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

Огромный размер БД [D7, Absolute Database]


Страницы:   1 2

Сергей Плоткин ©   (2004-08-12 23:45:00) 

Уважаемые знатоки,
Передо мной стоит такая проблема:
На данный момент пишу каталогизатор компакт-дисков. Программа использует базу данных (Absolute Database).

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

А теперь самое ужасное: закончил работу над процедурой и сделал пробный прогон (до этого запись в таблицу я закомментировал): взял диск с ~ 10000 файлами и запустил. И о'ужас, после добавления в таблицу 9996 файлов, файл базы данных стал занимать 27 мегабайт! Думал, ну может это на первый раз такое, потом меньше будет - запустил еще раз - 56 мегабайт!

Размеры каждой колонки я уже уменьшил, насколько это возможно. PageSize таблицы - 2550 (минимум, просто).

Господа знатоки, помогите пожалуйста, возможно ли как-то существенно уменьшить размер базы данных? Возможно есть встроенное сжатие какое-либо? Ведь 10000 строк текстовой информации должно сильно жаться...

p.s. Программа будет Freeware... Как я в глаза буду смотреть бедным пользователям, которые в обморок упадут после первого отсканированного диска?.. :)


Danilka   (2004-08-13 09:43:00) [21]

[11] 46_55_41_44 ©   (13.08.04 09:36)
В другом поле или другой таблице?
В любом случает, ты написал: 30 * 10 000 = 300 000
То-есть, по-твоему размер записи, то-есть размер всех полей записи всего 30 байт...
Если-же в другой таблице, то она тоэе будет в БД лежать, ее как-бы тоже посчитать надо. :))


46_55_41_44   (2004-08-13 09:36:00) [22]


> Что-то я тебя не пойму, как полный путь с именем файла и
> со всеми аттрибурами влезет в 30 байт?

Внимательнее читай, что я предлагал!!!
путь к файлу как раз в другом поле...


> 46_55_41_44 ©   (13.08.04 08:57) [5]
> Предлагаю тебе ввести собственную кодировку...
> Например:
> Бери расширение файлов, как уникальный ключ! (Файлы без
> расширения можно назвать например Untyped)
> Затем создаешь таблицу:
> FileType - String - Key Field
> FileName - String - Key Field
> FilePath - String - Key Field
> FileAttributes - String
> FileSize - LongInt


Danilka   (2004-08-13 09:34:00) [23]

[8] 46_55_41_44 ©   (13.08.04 09:25)
> Получается 30 * 10 000 = 300 000

Что-то я тебя не пойму, как полный путь с именем файла и со всеми аттрибурами влезет в 30 байт?

Сергей Плоткин
Если на самом деле очень надо уменьшить базу, то как вариант, сделать одну деревянную таблицу - каталог, с тремя полями:
id - integer
parent_id - integer
folder_name - varchar
а в таблице файлов писать не полный путь, а только имя файла, и в отдельную колонку id каталога.
Тоже, в какой-то мере нормализация. :))


46_55_41_44   (2004-08-13 09:28:00) [24]

Все сказанное мной является лишь моим мнением... Не претендую на абсолютность его (мнения)


46_55_41_44   (2004-08-13 09:25:00) [25]


> Anatoly Podgoretsky ©   (13.08.04 09:10) [6]
> 2550 * 10000 - 25 500 000  байт без учета служебных расходов

При всем уважении к вам Анатолий... я не претендую на ваши лавры...
Но все-таки...
255 * 10 000 = 2 550 000, что уже помоему лучше чем 40-50 мегов... и к тому же не обязательно брать все 255 символов... Думаю, что 50 хватит с лихвой!!! тогда 50 * 10 000 = 500 000, о чем я и говорил!!! Можно использовать не 2 символа для свойств, а 1... Тогда вариантов будет всего 9... ну  и что... помоему хватит... Тогда можно урезать еще размер символов на 20...
Получается 30 * 10 000 = 300 000

С другой стороны вы конечно же правы... мне бы его проблемы... что делать с БД размеров в несколько ГБ...


Anatoly Podgoretsky   (2004-08-13 09:11:00) [26]

Приведи так структуру таблицы (таблиц)


Anatoly Podgoretsky   (2004-08-13 09:10:00) [27]

2550 * 10000 - 25 500 000  байт без учета служебных расходов.
Уменьшить можно за счет нормализации, см. выше и за счет правильных типов полей и смены базы данных. А 10000 это не большое количество, может быть значительно больше.
Absolute Database это случайно не ADS и ты видимо выбрал dBase формат или их сообственный, не серверный. Эта база мало подходяше для указаных целей. Смотреть в сторону клиент серверных баз - MSDE, Firebird и других. Выбрать правильные типы и нормальную нормализацию. Сможешь снизить раза в два-три.
Но работать с базами большего размера и обижаться на размер нелепо. Нормальное явление 1-2 гб база.


46_55_41_44   (2004-08-13 08:57:00) [28]

Предлагаю тебе ввести собственную кодировку...
Например:
Бери расширение файлов, как уникальный ключ! (Файлы без расширения можно назвать например Untyped)
Затем создаешь таблицу:
FileType - String - Key Field
FileName - String - Key Field
FilePath - String - Key Field
FileAttributes - String
FileSize - LongInt

В FileType записываешь расширение файлов *.mp3, *.txt всу что угодно (Файлы без расширения -Untyped)

С FileName, FilePath, FileSize думаю все ясно...

Вот теперь самое главное...
FileAttributes...
Предлагаю вот что...
Ну сколько может быть например случаев и всяких там аттрибутов для файлов... Не очень много... Так вот...
В первые 2 символа записывай например информацию о аттрибутах..
Там всего 4 случая: Archive, Read-Only, Hidden, System... так вот 01 - Archive, 02- Read-Only... и т.д.
Во вторые 2 символа еще что-то... и т.д.
И так ты сможешь записать 255 div 2 = 122 набора свойств файлов... помоему достаточно... и у каждого свойства по 01..99 вариантов... Вариант 00 оставишь нп отсутствие данного типа в файле...
В конце у тебя получится строка типа 010206020120... (смотря сколько информации будешь писать)... Примечание: Все строки должны быть одинаковой длины...
Для этого тебе советую написать 2 функции...Одна для записи в базу другая для считывания...
и все...
работа не очень легкая... но зато нагрузка с БД перейдет на прогу... БД уменьшится до пары сотен кБ... если не меньше!!!


sniknik   (2004-08-13 08:20:00) [29]

> будет 3-6 мб... Что же будет, когда в базе будет 100 дисков.
300-600mb. ;о))

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

> то ничего такого пользователю не потребуется.
потребуется, а так говорят потому что в 95% случаев уже все установлено (ставится с системой, а если не ставится то есть вероятность что ктото до тебя поставил (многие используют))


Сергей Плоткин   (2004-08-13 00:53:00) [30]


> и немного за счет нормализации... не хранить все 60полей
> в одной таблице а выделить только основное, остальное с
> связываемых файлах. ну зачем тебе колонки о видео если файл
> текстовый? а так только тип в основных полях храниш и разные
> таблици с инфой о разных типах.

Ок, так и сделаю...

> и еще немного.. ;о) есть там в этом Absolute Database var
> поля? ну типа что в mssql/access если поле char(60) и ему
> 5 символов присвоить запись займет все одно 60 символов...
> а вот если varchar(60) то всего 4(указатель) + 5(данные)
> символов. экономия однакою ;о)

VarChar нет. Есть только VarBytes. Variable number of bytes (binary storage) пишут в хелпе. Это не то случайно?

> ну и еще чуть чуть... ;о)) юникод база держит? если да и
> по умолчанию включено то это *2 размер всех строк. найди
> и выключи. (если есть)

Поддержки Юникода, поверхностно взглянув, не нашел...

p.s. Все равно, получается, что существенно уменьшить размер не удастся?.. Вообще, я предполагал, что размер структуры каждого диска будет занимать не более 300-400 кб, а так я думаю, все равно даже при всех условиях, описанных выше, каждая структура будет 3-6 мб... Что же будет, когда в базе будет 100 дисков.
Поэтому, сразу назревает 2 вопроса:
1) Неужели в БД не бывает сжатия всех полей?
2) Насчет Access. Если создавать базу Access, то необходимо ли будет наличие каких-либо DLL Access (или самой установленной MS Access) на компьютере у стороннего пользователя? Слышал, что если управлять через ADO, то ничего такого пользователю не потребуется.


sniknik   (2004-08-13 00:13:00) [31]

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

и немного за счет нормализации... не хранить все 60полей в одной таблице а выделить только основное, остальное с связываемых файлах. ну зачем тебе колонки о видео если файл текстовый? а так только тип в основных полях храниш и разные таблици с инфой о разных типах.

и еще немного.. ;о) есть там в этом Absolute Database var поля? ну типа что в mssql/access если поле char(60) и ему 5 символов присвоить запись займет все одно 60 символов... а вот если varchar(60) то всего 4(указатель) + 5(данные) символов. экономия однакою ;о)

ну и еще чуть чуть... ;о)) юникод база держит? если да и по умолчанию включено то это *2 размер всех строк. найди и выключи. (если есть)

может еще чего можно придумать но... както не видится отсюда. ;)


Алхимик   (2004-08-13 00:03:00) [32]

Пересмотри структуру БД
Например в одну таблицу пиши инфу по
.mp3 (имя, теги и т.д.) в другую про .doc ...
Идея в том чтобы в одной записи было не 60 полей из которых не все актуальны, а не больше 10 например.


Страницы:   1 2

Наверх

Титульная страница Поиск, карта сайта Написать письмо