Размер mdb пугает

← →
XMAN © (2006-04-27 12:06) [0]

Был файл с данными base.mdb в нем было около 40 000 записей в одной таблице...файл занимал около 130 мегабайт

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

в чем прикол?

я думал программка не все удалила...так при открытии *.mdb через Access я увидел что таблица пустая...

чего я не вижу...или что я должен знать? помогите....

← →
Sergey13 © (2006-04-27 12:09) [1]

2XMAN © (27.04.06 12:06)
>или что я должен знать?
То, что удаление записей не вызывает автоматического высвобождения дискового пространства.

← →
XMAN © (2006-04-27 12:31) [2]

> То, что удаление записей не вызывает автоматического высвобождения
> дискового пространства.

а как мне сделать что бы файл стал меньше занимать...если например он не садержит записей или содержит но меньше

← →
Johnmen © (2006-04-27 12:33) [3]

Один из базовых принципов функционирования любой БД.
Размер уменьшается в результате упаковки БД. (не путать с зипом, раром и пр. :))

← →
Sergey13 © (2006-04-27 12:35) [4]

2 [2] XMAN © (27.04.06 12:31)
Я ни с аксесом ни с АДО не работаю, но вероятно можно как то упаковать файл.

← →
XMAN © (2006-04-27 12:39) [5]

> Размер уменьшается в результате упаковки БД.

так, я не понимаю...
если данных в нем нет..смысл его упаковывать?...может я про что-то забыл и не удаляю
мне не верится, что файл mdb не может уменьшатся в размерах без упаковки) при удалении в нем данных КАК ЭТО?

← →
XMAN © (2006-04-27 12:40) [6]

есди в папку накидать файлов..папка увеличивается в размере...
если с нее удалить несколько файлов она должна уменьшится...
а в этом случае нефига подобного? )

← →
Плохиш © (2006-04-27 12:44) [7]

> XMAN © (27.04.06 12:40) [6]

Так тебе то же показывается, что количество записей равно нулю.
Читай Johnmen © (27.04.06 12:33) [3] до полного понимания сути.

← →
XMAN © (2006-04-27 12:46) [8]

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

← →
Sergey13 © (2006-04-27 12:46) [9]

2[6] XMAN © (27.04.06 12:40)
Так у тебя в качестве базы аксес или файловая система?

← →
Delphi basic (2006-04-27 12:47) [10]

Открыть БД в Access"e (монопольно, т.е. никто в этот момент не должен с ней работать), зайти в меню <Сервис/Служебные программы/Сжать и восстановить базу данных>

← →
XMAN © (2006-04-27 12:48) [11]

> Так у тебя в качестве базы аксес или файловая система?

Access ...
файловая система это был выкрик )

← →
XMAN © (2006-04-27 12:50) [12]

> Delphi basic

в Accesse получилось...а можно ли это программно сделать?

← →
Delphi basic (2006-04-27 12:52) [13]

> XMAN © (27.04.06 12:50) [12]
>
> > Delphi basic
>
> в Accesse получилось...а можно ли это программно сделать?
>

Можно, но как, не знаю. Покопайся в VBA

← →
Sergey13 © (2006-04-27 12:54) [14]

2[11] XMAN © (27.04.06 12:48)
> файловая система это был выкрик )
А кричать не надо! 8-)
Когда ты из ведра воду выливаешь оно (ведро) меньше становится? Нет. Можно его обрезать? Можно. Но не нужно, ибо опять придется наливать и тогда придется наращивать ведро. Вот так и с БД. 8-)
А для случая "БД=файловая система" объем диска то не уменьшается при стирании файлов.

← →
sniknik © (2006-04-27 12:55) [15]

> есди в папку накидать файлов..папка увеличивается в размере...
> если с нее удалить несколько файлов она должна уменьшится...
но место на диске тоже не освободится... пока "корзину" не почистиш.

> а можно ли это программно сделать?
можно см. в справке Jet - файл MSJRO.CHM (при установленном полном мсоффисе ) метод CompactDatabase

← →
XMAN © (2006-04-27 12:55) [16]

> А для случая "БД=файловая система" объем диска то не уменьшается
> при стирании файлов.

тут я погорячился...но все же

помогите программно уменьшить размер файла...(архивацией)

← →
XMAN © (2006-04-27 13:16) [17]

подскажт кто как в Delphi это можно сделать?

← →
Slym © (2006-04-28 04:59) [18]

program MDBPack; {$APPTYPE CONSOLE} uses SysUtils,ActiveX,ComObj; const ConnStr="Provider=Microsoft.Jet.OLEDB.4.0;Data Source="; var DBEngine:variant; Source,Dest,Path:string; begin Source:=ParamStr(1); Path:=ExtractFilePath(Source); Dest:=Path+"compact.mdb"; DeleteFile(Dest); try CoInitialize(nil); try DBEngine:=CreateOLEObject("JRO.JetEngine"); DBEngine.CompactDatabase(ConnStr+Source,ConnStr+Dest); finally CoUnInitialize; end; RenameFile(Source,Source+".old"); RenameFile(Dest,Source); DeleteFile(Source+".old"); Writeln("Packed OK"); except on E:Exception do Writeln(Format("Raised exception: %s with message: %s",[E.ClassName,E.Message])); end; end.

← →
VadimSpb (2006-04-28 10:04) [19]

Sergey13 © (27.04.06 12:54) [14]
Когда ты из ведра воду выливаешь оно (ведро) меньше становится? Нет. Можно его обрезать? Можно. Но не нужно, ибо опять придется наливать и тогда придется наращивать ведро.

Примеры не совсем удачные. Если ведро воды вылить в презерватив - он раздуется (до мах размеров Базы ;-))). Вылили - сжался. Изначально же база не занимает такой объем!

sniknik © (27.04.06 12:55) [15]
но место на диске тоже не освободится... пока "корзину" не почистиш.
Это смотря как удалять.

Просто поясните, в чем "физика процесса", плз.

← →
sniknik © (2006-04-28 10:51) [20]

> Это смотря как удалять.
если удалять с "шифтом" то это практически с указанием сделать после удаления сжатие базы.

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

вот сам скажи что важнее скорость работы программы/sql сервера или 150/200 мег (да пусть и гиг) "забытого" дискового пространства?
прежде чем скажеш дисковое пространство учти, что постоянныо перераспределение размера файла на каждой операции это не только тормоза программы (не только программы, это и на системе скажется) но еще и "убитый" ресурс диска, приближение его "смерти".

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

← →
Asail (2006-04-28 19:37) [21]

Кстати, у меня такой вопрос возникал по поводу paradox-таблиц - в смысле, как им pack программно зафигачить? Может, кто сталкивался??? Если да, то как сие реализовать можно (через BDE)?

← →
Рустем © (2006-04-28 21:08) [22]

> Кстати, у меня такой вопрос возникал по поводу paradox-таблиц
> - в смысле, как им pack программно зафигачить?

... uses DBITYPES, DBIPROCS, DBIERRS; ... procedure PackTable(Table: TTable); var Props: CURProps; hDb: hDBIDb; TableDesc: CRTblDesc; begin Table.Open; Check(DbiGetCursorProps(Table.Handle, Props)); FillChar(TableDesc, sizeof(TableDesc), 0); Check(DbiGetObjFromObj(hDBIObj(Table.Handle), objDATABASE, hDBIObj(hDb))); StrPCopy(TableDesc.szTblName, Table.TableName); StrPCopy(TableDesc.szTblType, Props.szTableType); TableDesc.bPack := True; Table.Close; Check(DbiDoRestructure(hDb, 1, @TableDesc, nil, nil, nil, False)); Table.Exclusive:=TRUE; Table.Open; Check(dbiRegenIndexes(Table.Handle)); end;

← →
Palladin © (2006-04-28 22:33) [23]

> XMAN ©

для здоровья нервей с БД лучше не связывайся, боюсь придется везти тебя в реанимацию при виде небольшой базы в 2-3 гб...

← →
VadimSpb (2006-04-28 22:34) [24]

sniknik © (28.04.06 10:51) [20]

Спасибо. Типа быстрое форматирование, где изменяются только заголовки разделов. Вывод: это вопросы быстродействия при записи БД на диск(разметка и т.д.). Однако, более критичным здесь представляется просто дефрагментация БД. Или я не прав?

← →
VadimSpb (2006-04-28 22:59) [25]

Под дефрагментацией, разумеется, понимается БД как файл :-))

← →
sniknik © (2006-04-28 23:08) [26]

ну, дефрагментацию диска тоже не после каждого удаления/добавления файла делают... так, время от времени.

> Однако, более критичным здесь представляется просто дефрагментация БД. Или я не прав?
в смысле? где сдесь? при упаковке базы?
скорее не самой БД, а индексов... так думаю. а данные не важно по каким смещениям лежат +100байт или +10000, это "глубоко парралельно".

← →
sniknik © (2006-04-28 23:12) [27]

> Под дефрагментацией, разумеется, понимается БД как файл :-))
а, в смысле чтобы сам базы не был фрагментирован. ну это да, важно, наверняка. чем проще системе читать/писать файл тем проще и движку sql делать манипуляции внутри его...

← →
VadimSpb (2006-04-28 23:43) [28]

В общем, логично. Это явно коррелирует с результатом сжатия БД напр. зипом или раром - объем файла уменьшается удивительно!

... знаеш, до последней твоей фразы ([28]), мне казалось что меня понимают... ;(

← →
VadimSpb (2006-04-29 00:35) [30]

Смущает зип-рар? :-)) Понятно что сжать-разжать БД это другое :-)))))
Я думал ты поймешь ... Если большой файл, например БД, реально внутри полупустой, то процесс сжатия становиться весьма эффективным.
Просто у меня диссер успешно защищен по сжатию. Возможно у меня немного другая терминология. Главное - понять физику процесса. Это сленг. Совсем не мешает логике ;-))

> Если большой файл, например БД, реально внутри полупустой, то процесс сжатия становиться весьма эффективным.
с точки зрения архиватора "например БД" не будет полупустой, даже если внутри все до последней таблици удалено... т.к. удаление логическое, т.е. просто указателю присвоено "вот туда можно писать", физически по вышеприведенным причинам там никто нулями пространство не трет, остаются старые данные. просто адреса где что лежит потерялись. но архиватор то про внутреннюю логику размещения данных не в курсе... аналогия не уместна.

← →
VadimSpb (2006-04-29 10:43) [32]

> ... аналогия не уместна

Очень даже уместна, хоть я и занимался сжатием изображения, а не баз.
Архиватор конечно тупой (зип, рар), сжимает без потери данных и внутр. структуру не понимает. Моя мысь была основана на практике.
Прожу эксперимент:
База mdb объемом 12 255 232. Сжал - 1 062 877. Это исходные параметры.
Удалил записи из одной таблицы в количестве 5500. Всего таблиц около 15 и они менее объемны. Сохранил файл, получил - 12 267 520, т.е. увеличился. Забавно.
Сжал - 738 038.
Вывод: После удаления записей процесс сжатия становится более эффективным, хотя объем файла немного увеличился. Наверное не только заголовки (адреса и т.д.) удаляются, но и какие-то данные.

> VadimSpb (29.04.06 10:43) [32]

А ты проведи этот эксперимент много раз с разными данными и базами. Увидишь, что никакой зависимости между объемом заархивированной базы и количеством удаленных записей вообще нет :-) Как на самом деле внутренние структуры mdb-файла изменяются при удалении, ведает только сама Access. Но то, что при удалении записей не удаляются никакие данные - это факт.

← →
VadimSpb (2006-04-29 21:44) [34]

> А ты проведи этот эксперимент много раз с разными данными
> и базами.

И причем здесь количество раз??? Может к шаманам обратиться?
Сколько угодно экспериментируй и с разными базами, результат будет как в [32]. Просто замечено длительной практикой.

> Как на самом деле внутренние структуры mdb-файла изменяются
> при удалении, ведает только сама Access.

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

← →
VadimSpb (2006-04-29 23:29) [35]

sniknik © (28.04.06 10:51) [20]

Основная мысль как я понял - более быстрый процесс записи если файл БД размечен. Пробуем проверить. База та же что и в [32].
Вводим запросом 5000 записей, файл "не размечен".
1. Время работы - 12,43 - 12,48 мкс. Пробовал 5 раз. Таймер высокоточный от LMD.
2. Удалил все новые записи, остались только 5500 старых. Т.е. файл теперь весит около 20 МБ и типа "размечен".
Вводим запрос. Время работы 12,71 - 12,91. Явное увеличение времени работы, хотя ожидается обратный результат. ПРИЧЕМ ПОСЛЕ нескольких запросов, когда БД стала "неразмеченой", время работы сразу уменьшилось до п.1. Предвижу результат на базе 1-2 ГБ ;-)))
Можете прокомментировать?

> VadimSpb (29.04.06 21:44) [34]

Сейчас провел эксперимент - база с одной-единственной таблицей с 184 тыс. записей (тел. справочник Донецка за 2004 год, если интересно :-), весит 26 метров, Access 2003. Очистил таблицу полностью. Размер файла после удаления остался практически прежним - 26 метров. А вот при архивировании действительно уменьшился - с 5.5 до 4 метров.
Впрочем, этому есть объяснение - данные, естественно, Access не трогает. Зато индексы наверняка честно вычищает. А индексы к таблице порой занимают места намного больше самой таблицы...

> Можете прокомментировать?
могу... но смысл? все одно извратиш...

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

движок jet-а не дураки писали, для каждой записи выделения обьема не будет, т.е. когда пишеш в новый файл выделяется кусок (страница) памяти куда и идет запись, возможно все твои 5500 записей в одну страницу и поместились... выделение 1 раз, т.е. мизер по времени. а запись без проверок, никаких "указателей" (пусто/занято) проверять не надо вот и чуть быстрее.
дурацкий тест, ничего он не проверяет.

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

← →
VadimSpb (2006-04-30 11:42) [38]

> могу... но смысл? все одно извратиш...

> дурацкий тест, ничего он не проверяет.

Конечно, если практика опровергает теорию [20] ;-))

Речь идет о понимании того, что происходит в БД при операциях записи/удаления.
Еще раз поэкспериментировал уже с сотнями тысяч записей. Результат еще наглядней, только дольше проверять :-((
После того, как базу сжали/разжали - запись, напр. 100 000 строк, идет 86,05 - 88,02 с. Если перед этим этот объем несколько раз ввести, а потом удалить одним запросом - этот объем будет записываться уже 102,36 - 104,82 с. Разумеется, не следует после каждой записи БД сжимать/разжимать - это абсурд. Также ясно, что эти данные касаются моей машины и условиям примера. Главное - динамика.
Просто это противоречит твоим утверждениям в [20] о повышении скорости работы когда есть выделенная/размеченная (называй как угодно) область.
И далее. Файл 100 МБ. Ввели 100 000 записей - он стал 121 МБ.
Удалили - остался практически тем же.
Ввели еще раз 100 000 записей - файл стал 143 МБ! Т.е. не хочет он писать в ту область, о которой ты говоришь. Почему?
А если мне понадобиться постоянно гонять из БД в БД миллионы записей? Поэтому и есть желание понимать эти процессы.

Можно конечно сказать, что тест - дурацкий, юзер - начинающий извращенец, времени мало и послать всех в Библиотеку.
А можно не полениться, сваять простой пример и проверить свои утверждения на практике.

> VadimSpb (30.04.06 11:42) [38]

> Можно конечно сказать, что тест - дурацкий

Тест действительно дурацкий - потому что на сколько-нибудь серьезных СУБД (MS SQL, или тот же Firebird) все работает в соответствии с теорией. А Access... никому не придет в голову гонять миллионы записей в СУБД Access

> Конечно, если практика опровергает теорию [20] ;-))
в том то и дело, это не практика это подтасовка, выбран процес который только боком этого касается и где выделение минимизировано разработчиками движка.
и на этом делаются выводы... поэтому и дурацкий. а вовсе не потому что чтото опровергает.
говорил же, извратиш.

> Ввели еще раз 100 000 записей - файл стал 143 МБ! Т.е. не хочет он писать в ту область, о которой ты говоришь. Почему?
да потому, что не все так просто как в примере, чтобы обьяснить упрощают... фактически, то что я привел, это будет верно только для одной страници, ссылки эти. но есть же еще область где описаны сами страници (для дисков аналогия область FAT), есть рабочие области (упакуй базу и после простой запрос на чтение, лучше с обьеденением(join) делаеш и... чудо, база увеличилась а ты туда даже ничего в нее не писал...), есть типы полей которые имеют переменную длинну, а ты в "тесте" не привел даже структуру, хотя там единственная запись может быть размером от 4 байт до чуть меньше 2 гигабайт... тем не менее тоже делаеш "выводы".
хотя структура конечно тут не поможет, не только от нее размер зависит, и все факторы просчитать не удастся, это уже к разработчикам движка, хотя не думаю что и они это четко скажут.

> времени мало и послать всех в Библиотеку.
я тебя посылал? или всетаки пытался обьяснить?

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

Размер mdb пугает Найти похожие ветки