Размер 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]

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

← →
sniknik © (2006-04-29 00:23) [29]

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

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

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

← →
sniknik © (2006-04-29 01:06) [31]

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

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

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

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

← →
DrPass © (2006-04-29 20:25) [33]

> 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 ГБ ;-)))
Можете прокомментировать?

← →
DrPass © (2006-04-29 23:52) [36]

> VadimSpb (29.04.06 21:44) [34]

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

← →
sniknik © (2006-04-30 02:04) [37]

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

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

движок 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 МБ! Т.е. не хочет он писать в ту область, о которой ты говоришь. Почему?
А если мне понадобиться постоянно гонять из БД в БД миллионы записей? Поэтому и есть желание понимать эти процессы.

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

← →
DrPass © (2006-04-30 12:44) [39]

> VadimSpb (30.04.06 11:42) [38]

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

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

← →
sniknik © (2006-04-30 12:57) [40]

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

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

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

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

← →
VadimSpb (2006-04-30 12:59) [41]

В Accesse теория другая??? Что-то это мне напоминает ... :-)))
Хотя [1] все начиналось именно с Access-а.
Нет проблем, сейчас в MS SQL проверю ...

← →
sniknik © (2006-04-30 13:16) [42]

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

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

← →
VadimSpb (2006-04-30 13:35) [43]

sniknik © (30.04.06 12:57) [40]

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

В чем подтасовка? Я честно записываю 100000 фамилий абонентов "ХХХХХХХХХХ". Очень даже часто встречающаяся у меня задача. Если разработчики движка оптимизировали его для каких-то определенных целей, то неплохо бы знать для каких. Если моя задача выполняется неоптимально, то надо принимать какие-то меры. Берешь секундомер и считаешь как быстрее работает. Иногода сомневать оказывается очень даже полезно, результаты улучшаются!

> я тебя посылал? или всетаки пытался обьяснить?

Спасибо. Я не часто сюда захожу, когда совсем припрет - нет информации, а не понимаешь что-либо. Однажды мне даже предложили сжечь Архангельского, в смысле его книги :-)))

> тем более доказательством ты почемуто считаеш размер

РАЗУМЕЕТСЯ. Размер/время - это количественные показатели, которые характеризуют быстродействие программы. Нормальный программист ищет не типовые решения, а ОПТИМАЛЬНЫЕ для конкретной задачи.

Ладно, дальше нет смысла обсуждать.

← →
VadimSpb (2006-04-30 13:43) [44]

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

Если разработчики автомобильного двигателя оптимизируют его на скорость 300 км/ч с расходом 1 л., а для скорости 60 км/ч - расход 100л., ты купишь такую машину за те же деньги, где расход на 60 км будет 5 л.?
Не купишь, потому что в городе ездишь.
Так и в софте - ищешь оптимальные алгоритмы. Графикой никогда не занимался? Уверяю - еще тем станешь оптимизатором!
В базах я смотрю то же. Как запрос составишь - так он и отработает. Можно конечно, клиента запарить большой теорией, что все круто, но как- то неприлично это ...

← →
sniknik © (2006-04-30 13:55) [45]

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

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

а то приближение к реальности ([37]), что я предложил, ты попросту игнорировал.

> Ладно, дальше нет смысла обсуждать.
согласен

← →
VadimSpb (2006-04-30 14:07) [46]

> ты выбрал то, где

Еще раз: я не выбирал ничего специально. ТИПОВАЯ ОПЕРАЦИЯ перекачки БД. И ее мне надо оптимизировать. ИМЕННО ЕЕ. У меня эта задача - реальность, а не в [37].
По Хонде. Ты сам подсознательно понимаешь меня. Если есть задача проехать мах быстро, то на масло и бензин внимания обращать не будем, как в Формуле 1 :-))). Если цель ставится о неких равных условиях - то на велосипеде быстрее. Так и у меня в примере - оптимизация программы по конкретному показателю - быстродействие, а не по сумме усредненных.
Природу не обманешь - где-то улучшил, в чем то проиграл.

Ладно, закончили. Футбол начался, пора смотреть :-))

← →
Anatoly Podgoretsky © (2006-04-30 14:14) [47]

VadimSpb (30.04.06 11:42) [38]
Потому что есть понятия транзакции. Запись пишется в новое место, старая остается мусором до упаковки.
Гонять миллионы записей в Акцесс - это быть не в ладах с головой.

← →
VadimSpb (2006-04-30 14:16) [48]

> Гонять миллионы записей в Акцесс - это быть не в ладах с
> головой

Да.

← →
sniknik © (2006-04-30 14:38) [49]

> И ее мне надо оптимизировать. ИМЕННО ЕЕ.
но спрашивал то ты НЕ ЭТО. откуда мне знать твои тайные мотивы, я говорил про то о чем спрошено.

> Гонять миллионы записей в Акцесс - это быть не в ладах с головой.
а период "гона" учитывается? ;о))

ну к примеру, есть прога (реально есть) используется для связки между бэк и фронт оффисами (касса и 1с), один из вариантов она работает с mdb базой...
справочник товаров полный в одном тоже реальном месте 100тыс записей, прогрузку полную они делают каждое утро... т.е. милион это 10 дней всегото. на самом деле даже меньше т.к. кроме товаров есть такойже, и даже больше справочник баркодов (некоторые товары представлены несколькими баркодами) т.е. уже 200тыс каждое утро. плюс дисконты, это таблица гдето 150-200тыс. и плюс в процессе работы, в течении дня, все что обновляется тут же передается на кассы. т.е. 1 милион это гдето 1 - 3 дня. прогоняется через mdb. (именно прогоняется, т.к. после передачи записи удаляются). и ничего работает. подумать сколько милионов было пергнано за 2 года (патриарх кому первому ставили уже 6 лет... правда там обьемы не те)... ужас просто. ;о))

могу я считать что у меня "не лады с головой" если программу писал я? ;)

p.s. это, пост [49] шутка конечно, в сиысле я не расчитывал что прогу будут так использовать. когда писалось, тестировали ("стресс" тесты делали), и расчитывали mdb версию на максимум 3 кассы (потому как "стресс" на 5 начал глючить), если больше то должно быть mssql. кто знал, что менеджеры после ее на 20 "впарят" именно mdb версию... но тем не менее работает. правда я "открестился" от всех возможных глюков уже после случая такой продажи на 9 касс, в письменной форме. что радует. ;о))

Делать периодический Compact если кого то это беспокоить.
Новые записи не оказывают пагубного воздействия. Пагубно удаление и возможно изменение. Размер тогда растет катастрофически. Но беспокоиться до примерно 2 гб не о чем.

> Но беспокоиться до примерно 2 гб не о чем.
примерно... гдето на 1.8 гиг, у нас начинались глюки, ошибки разные выдавало. не часто и не всегда, зависело от запросов и интенсивности обращений, 1 раз мне удалось сложным запросом на таком размере практически "убить" базу (аксесовский компакт & репайр не справился), правда частично база работала, т.е. по одной двум записям можно было удалять/добавлять, все запросы после того висли, открывать таблицы получалость только в режиме серверного курсора. после удаления какогото количества записей (большого, не помню точно сколько) репайр сработал.
тот же запрос на меньшей й базе (1.5) отрабатывал множество раз без проблем (ни одного глюка получить не удалось)
размер мерялся после упаковки баз. т.е. "чисто" данные. после запросов, что база на 1.8, что на 1.5 гиг становилась размером 2 гига (т.е. запросы проверяли обьемные с джойнами, естественно логично предположить, что чем проще запросы с которыми работаеш, тем ближе граница "дедлайна" к 2м гигам).

"разрулить" это тогда не удалось (может и счас не удастся, но больше не пытаемся ;), а может наоборот не удастся воспроизвести... тогда это 2000-2001 год, база access-2000, MDAC-2.5/2.6 jet 3/4sp сейчас и не найти ;), просто написали в рекомендациях, что после 1.5 гиг часть данных требуется скидывать в архив (механизм есть, деление по годам/кварталам/месяцам). архив ничем не отличается от рабочей базы, отчеты получить из него можно, исправить в нем ничего нельзя (в программе, если аксессом открыть то конечно... но тут сами виноваты ;о)).

← →
VadimSpb (2006-04-30 18:50) [53]

> Anatoly Podgoretsky © (30.04.06 14:14) [47]
> VadimSpb (30.04.06 11:42) [38]
> Потому что есть понятия транзакции. Запись пишется в новое
> место, старая остается мусором до упаковки.

Почему?
В [20] утверждается что все размечено (типа в шоколаде) и теперь работать будет быстрее ... Мои примеры показывают что если это и так - то не всегда. Теперь оказывается, что это мусор.
Зачем? И где тогда логика опять из [20]?
Не думайте, что я цепляюсь, просто Ваши ответы противоречивы и вызывают еще больше вопросов. Действительно охота разобраться. Придется видно поискать соотв. литературу.

> В [20] утверждается что все размечено (типа в шоколаде) и теперь работать будет быстрее ...
в [20] нет ни слова о какойто разметке... выдумываеш.

← →
VadimSpb (2006-04-30 19:20) [55]

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

Разве речь не об этом?

разметка, это это не выделение памяти, это "нанесение меток внутри этой памяти" ну чтото типа этого. вот форматирование диска это разметка, а выделение, это создание раздела по аналогии. абсолютно разные понятия.

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

← →
VadimSpb (2006-04-30 20:48) [57]

sniknik ©, Уважаемый верить или не верить дело личное.
Я предпочитаю проверять с калькулятром/секундомером ...
Просто твои объяснения весьма расплывчаты и меня не удовлетворили.
Из твоего поста [20] следует что увеличение объема БД это хорошее решение разработчиков движка. Я же показал что не всегда это так. ВОТ И ВСЕ!
Когда ты учился в институте тебе читали лекции, где говорилось что хорошо/быстро, а что плохо/медленно. После 2-4 лекций была лабораторная, где индикаторы со стрелочками подтверждали слова преподавателя. Если бы в том же [20] была оговорка, что такое выделение памяти не всегда является благом, то и постов бы столько небыло. В моей задаче это даже вредно, т.к. просто чаще придется сжимать/разжимать БД. Тут уж ... задача такая :-)))) Объем ограничен 4 ГБ Express-ом 2005.
Спасибо.

" В системах управления транзакциями почти всех баз данных промежуточные изменения хранятся в некотором временном файле журнала, вместо немедленной их записи в БД. Аналогично, MS Jet буферизует все результаты работы транзакции во временной базе данных.Когда транзакция фиксируется, содержимое временной базы данных переносится в реальную БД.
MS Jet не создает временную базу данных, пока это не потребуется. В начале для хранения изменений к данным он использует любую доступную кэш-память. После того, как кэш исчерпан, процессор создает временную базу данных и начинает записывать изменения туда.
...
Хотя временная база данных- база данных MS Jеt, она внутренне используется только процессором.Ее нельзя открыть из другого приложения.После завершения транзакции процессор освобождает пространство временной базы данных.
...
MS Jet автоматически инициирует внутренние транзакции для всех операций по добавлению, модификации и удалению данных."
Цитата из бумажной книги, поэтому ссылку не привожу.
Относится к MS Jet 3.5

← →
VadimSpb (2006-04-30 20:53) [59]

← →
VadimSpb (2006-04-30 21:05) [60]

> MS Jet автоматически инициирует внутренние транзакции для
> всех операций по добавлению, модификации и удалению данных

Вот что, когда и как при этом происходит интересует прежде всего. В этом бумажном варианте ничего про это не сказано?
В т.ч. для MS SQL.

Посылку оплатишь? Тебе же сказали из бумажной книги.

← →
VadimSpb (2006-04-30 21:08) [62]

Я уже понял. Сообщи реквизиты. Возможно, будет от чего отталкиваться при поиске литературы.

> Я же показал что не всегда это так. ВОТ И ВСЕ!
ты этого НЕ ПОКАЗАЛ! ты взял вариант где обсуждаемые операции НЕ УЧАСТВУЮТ, вернее их так мало что ими можно пренебреч. и из 2-х вариантов операций, даже которыми пренебрегаем участвует 1-н наименее ресурсоемкий.

это и называется подтасовкой.

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

О каком Express-е пошла речь

← →
VadimSpb (2006-04-30 21:21) [65]

:-)))))
Я взял вариант который нужен МНЕ не имея никакого понятия об операциях.

> оно всегда является благом, если расматривать сумму факторов,
> процес в обшем.

Это - средняя температура в больнице. И это является ПОДТАСОВКОЙ. Такие рассуждения напоминают впаривание чего-либо клиенту. ЭТО ОТЛИЧНЫЙ ДВИЖОК. Можно и не упоминать, что для конкретной задачи есть более оптимальные решения. Работал у меня один студент. У него все клиенты были тупыми и ничего не понимали в том, что хотят. Перевоспитанию не поддавался, поэтому был уволен.

> Я взял вариант который нужен МНЕ не имея никакого понятия об операциях.
там тоже самое, движок аналогичен MSSQL 2005. продукт того же мелкософта. (т.е. тут даже не принципы, тут детали реализации могут быть подобные)

> Это - средняя температура в больнице. И это является ПОДТАСОВКОЙ.
допустим, тогда скажи, как ты собираешся обеспечивать постоянную запись в чистые, только выделенные страници базы, если не будет упаковок? ... т.е. у тебя не будет удалений? а чего тогда в "тесте" оно присутствует? зачем меряеш температуру не больного, а прохожего рядом с больницей? он то тут при чем?

кстати какое впаривание? говорили вроде о процессе безотносительно движка, аксесс как пример потому как тема с него начиналась.

← →
VadimSpb (2006-04-30 22:31) [67]

Сейчас гоняю тот же тест как [38] но в MS SQL 2005 Express. Все значительно дольше и места больше ест :-(((.
Просто задача состоит в периодических записях части клиентской базы 300-400тыс. строк. В идеале мне и затирать данные специально не надо. Было бы прекрасно: стерлись заголовки и пишем новые данные поверх старых. Просто и со вкусом, одним словом - оптимально. В Accesse так не пройдет, файл быстро будет максимальным. Или надо сжать/разжать. 2005 я смотрю очень долго все делает.
Проще будет просто удалять файл базы и создавать новый. Access, кстати значительно пошустрее.

> кстати какое впаривание? говорили вроде о процессе безотносительно
> движка, аксесс как пример потому как тема с него начиналась.
>

Я не хотел тебя задеть. Просто я давно уже объясняю, что мой тест выбран только исходя из моих задач, а ты как будто этого не слышишь. Просто убеждаешь, что идейная реализация в движках отличная. Очень похоже на убеждение клиента в чем либо :-0)))
Я и не сомневаюсь что движки пишут грамотные люди. Просто есть золотое правило - если тебе говорят, что то, то и то круто, сразу поинтересуйся за счет чего это достигнуто и где оказалось хуже. Природу не обманешь. Может тот худший параметр и будет для тебя наиболее важным.

VadimSpb (30.04.06 22:31) [67]
Сейчас гоняю тот же тест как [38] но в MS SQL 2005 Express.
...
Было бы прекрасно: стерлись заголовки и пишем новые данные поверх старых.

MS SQL не пишет новых данных поверх старых.

Access, кстати значительно пошустрее.

Зависит от методики измерения, если Акцесс локальный, то может быть быстрее, а может и нет. В сетевом варианти почти всегда проиграет.

По возможности он вообще не пишет данные в базу. Пишется лог

> Access, кстати значительно пошустрее.
в локальном варианте (и аксесс и mssql на одной машине, где и клиент) да шустрее, но не значительно (в разы разници нет). в нормальном варианте (сервер на одной машине клиенты на других) mssql быстрее.

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

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

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