![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Размер mdb пугает [D7, ADO]
XMAN © (2006-04-27 12:06:00)Был файл с данными base.mdb в нем было около 40 000 записей в одной таблице...файл занимал около 130 мегабайт
я удалил все записи, а он так и остался с таким же размером...может немного уменьшился )...
в чем прикол?
я думал программка не все удалила...так при открытии *.mdb через Access я увидел что таблица пустая...
чего я не вижу...или что я должен знать? помогите....
VadimSpb (2006-04-29 00:35:00) [41]Смущает зип-рар? :-)) Понятно что сжать-разжать БД это другое :-)))))
Я думал ты поймешь ... Если большой файл, например БД, реально внутри полупустой, то процесс сжатия становиться весьма эффективным.
Просто у меня диссер успешно защищен по сжатию. Возможно у меня немного другая терминология. Главное - понять физику процесса. Это сленг. Совсем не мешает логике ;-))
sniknik (2006-04-29 00:23:00) [42]... знаеш, до последней твоей фразы ([28]), мне казалось что меня понимают... ;(
VadimSpb (2006-04-28 23:43:00) [43]В общем, логично. Это явно коррелирует с результатом сжатия БД напр. зипом или раром - объем файла уменьшается удивительно!
sniknik (2006-04-28 23:12:00) [44]> Под дефрагментацией, разумеется, понимается БД как файл :-))
а, в смысле чтобы сам базы не был фрагментирован. ну это да, важно, наверняка. чем проще системе читать/писать файл тем проще и движку sql делать манипуляции внутри его...
sniknik (2006-04-28 23:08:00) [45]ну, дефрагментацию диска тоже не после каждого удаления/добавления файла делают... так, время от времени.
> Однако, более критичным здесь представляется просто дефрагментация БД. Или я не прав?
в смысле? где сдесь? при упаковке базы?
скорее не самой БД, а индексов... так думаю. а данные не важно по каким смещениям лежат +100байт или +10000, это "глубоко парралельно".
VadimSpb (2006-04-28 22:59:00) [46]Под дефрагментацией, разумеется, понимается БД как файл :-))
VadimSpb (2006-04-28 22:34:00) [47]sniknik © (28.04.06 10:51) [20]
Спасибо. Типа быстрое форматирование, где изменяются только заголовки разделов. Вывод: это вопросы быстродействия при записи БД на диск(разметка и т.д.). Однако, более критичным здесь представляется просто дефрагментация БД. Или я не прав?
Palladin (2006-04-28 22:33:00) [48]
> XMAN ©
для здоровья нервей с БД лучше не связывайся, боюсь придется везти тебя в реанимацию при виде небольшой базы в 2-3 гб...
Рустем (2006-04-28 21:08:00) [49]
> Кстати, у меня такой вопрос возникал по поводу 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;
Asail (2006-04-28 19:37:00) [50]Кстати, у меня такой вопрос возникал по поводу paradox-таблиц - в смысле, как им pack программно зафигачить? Может, кто сталкивался??? Если да, то как сие реализовать можно (через BDE)?
sniknik (2006-04-28 10:51:00) [51]> Это смотря как удалять.
если удалять с "шифтом" то это практически с указанием сделать после удаления сжатие базы.
> Просто поясните, в чем "физика процесса", плз.
какая физика? тут логика, операции перераспределения памяти/дискового пространства/файла длительны и ресурсоемки, а вот перезапись внутри уже выделенного пространства нет, значит логично минимизировать эти операции, считать что память/обьем файла один раз выделенная будет принадлежать программе/файлу до явного указания освободить ее. программе же явно, каждый раз указывать незачем, после удаления может сразу пойти запись (в базах сплош и рядом) и в случае уже имеющегося(выделенного) пространства она пойдет с минимальными задержками. само же удаление чисто логическое, просто указателю гдето в структуре присваивается значение что смотрит он не на данные, а на свободное для записи место, и все. просто и с минимумом "телодвижений".
все и всё так делают, а если нет то такой программе/движку место в мусорной корзине...
вот сам скажи что важнее скорость работы программы/sql сервера или 150/200 мег (да пусть и гиг) "забытого" дискового пространства?
прежде чем скажеш дисковое пространство учти, что постоянныо перераспределение размера файла на каждой операции это не только тормоза программы (не только программы, это и на системе скажется) но еще и "убитый" ресурс диска, приближение его "смерти".
про память упоминал потому, что и ее это тоже касается (одни и теже цели преследуются, и поведение похоже), а тут часты вопросы типа почему программа занимает память хотя я ее освободил... а потому. память тоже не перерастпеделяется по каждому чиху программиста, а только при нужде, по требованию системы.
VadimSpb (2006-04-28 10:04:00) [52]Sergey13 © (27.04.06 12:54) [14]
Когда ты из ведра воду выливаешь оно (ведро) меньше становится? Нет. Можно его обрезать? Можно. Но не нужно, ибо опять придется наливать и тогда придется наращивать ведро.
Примеры не совсем удачные. Если ведро воды вылить в презерватив - он раздуется (до мах размеров Базы ;-))). Вылили - сжался. Изначально же база не занимает такой объем!
sniknik © (27.04.06 12:55) [15]
но место на диске тоже не освободится... пока "корзину" не почистиш.
Это смотря как удалять.
Просто поясните, в чем "физика процесса", плз.
Slym (2006-04-28 04:59:00) [53]
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.
XMAN (2006-04-27 13:16:00) [54]подскажт кто как в Delphi это можно сделать?
XMAN (2006-04-27 12:55:00) [55]
> А для случая "БД=файловая система" объем диска то не уменьшается
> при стирании файлов.
тут я погорячился...но все же
помогите программно уменьшить размер файла...(архивацией)
sniknik (2006-04-27 12:55:00) [56]> есди в папку накидать файлов..папка увеличивается в размере...
> если с нее удалить несколько файлов она должна уменьшится...
но место на диске тоже не освободится... пока "корзину" не почистиш.
> а можно ли это программно сделать?
можно см. в справке Jet - файл MSJRO.CHM (при установленном полном мсоффисе ) метод CompactDatabase
Sergey13 (2006-04-27 12:54:00) [57]2[11] XMAN © (27.04.06 12:48)
> файловая система это был выкрик )
А кричать не надо! 8-)
Когда ты из ведра воду выливаешь оно (ведро) меньше становится? Нет. Можно его обрезать? Можно. Но не нужно, ибо опять придется наливать и тогда придется наращивать ведро. Вот так и с БД. 8-)
А для случая "БД=файловая система" объем диска то не уменьшается при стирании файлов.
Delphi basic (2006-04-27 12:52:00) [58]
> XMAN © (27.04.06 12:50) [12]
>
> > Delphi basic
>
> в Accesse получилось...а можно ли это программно сделать?
>
Можно, но как, не знаю. Покопайся в VBA
XMAN (2006-04-27 12:50:00) [59]
> Delphi basic
в Accesse получилось...а можно ли это программно сделать?
XMAN (2006-04-27 12:48:00) [60]
> Так у тебя в качестве базы аксес или файловая система?
Access ...
файловая система это был выкрик )