Большая БД на Access2000 и ADO

← →
FatalWay © (2004-07-11 09:01) [0]

Можно ли использовать связку Access2000 + ADO + Delphi7, если БД будет 200-700 Mb???
Клиент делает только запросы Select.
БД лежит но компе юзера или в локалке.
Если связка неприемлема что поменять???

← →
YurikGL © (2004-07-11 09:07) [1]

Можно, но, скорее всего, тормоза будут.

← →
YurikGL © (2004-07-11 09:28) [2]

Кстати, > 200-700 Mb??? это в сжатом виде? И какое количество записей планируется? Может 200-700 Мб картинок?

← →
sniknik © (2004-07-11 10:47) [3]

200-700Mb для access ерунда, проблемы начинаются после 1.5gb (размер считать в упакованом виде, в рабочем состоянии это будет 1,8-1,9гиг, да, это проверялось на jet sp6 есть уже sp8 там может быть уже по другому)

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

← →
Zlod3y (2004-07-11 10:55) [4]

при таких размерах акцес - это ацтой...... попробуй DBase

← →
Zlod3y (2004-07-11 10:58) [5]

мне как-то кто-то из мастеров сказал что акцес и скорость не совместимые вещи.....также как микрософт и безопасность :-D

через ADO не советую, медленно слишком, пробуй ODBC-драйвера они быстрее раза в 2-2,5.....лично испытания проводил

← →
sniknik © (2004-07-11 11:17) [6]

Zlod3y (11.07.04 10:58) [5]
небось с BDE начинал? не для подкола, просто привыкшие к BDE и его методам замечательно там работающим именно на медленность жалуются при переходе на ADO.

> пробуй ODBC-драйвера они быстрее раза в 2-2,5
для вас это может быть откровением но ODBC работает через Jet (OLE DB для ADO), т.е. связка получается "ваши компоненты"->ODBC->ADO->Jet->"база" вместо возможного ADO->Jet->"база"
очень быстро ;о), а еще с десяток промежуточных добавить так просто скорость света будет ;о))).

может ты както не так того мастера понял?

← →
Zlod3y (2004-07-11 13:01) [7]

Я начинал с БДЕ, потом ушёл в АДО, теперь возращаюсь обратно!

Может я неправильно выразился!
Для работы с АДО я использовал компоненты TADOConnection, TADOTable и TADOQuery, но при использовании ОДБЦ я пользуюсь исключительно TDataBase, TTable и TQuery.....

Эксперимент был такой:
в базу, состоящей из одной таблицы с двуми полями: "ID" и "Дата+Время", вводилось 65535 записей.

На моей домашней машине: Cel 700, 256 мб ОЗУ, довольно медленный 10-гиговый квантум, вин 2000 про

почему-то при связке TTable-ОДБЦ-"база.mdb" такой массив записей был введён за 27 минут!

при связке TADOTable-Jet-"база.mdb" после 6-ой тысячи я всё выключил, так как ждать замучался, причём на лицо был эффект замедления....чем больше становилась база, тем медленное заносились записи, при такой связке!

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

С уважением к Мастерам!

← →
sniknik © (2004-07-11 13:45) [8]

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

еще вывод: учите sql, а также настройки ado. прямой перенос методов с BDE недопустим.

> можете подобный эксперимент провести сами. если можно, то хотелось бы знать результаты...
честно? уже заколебался их проводить, эти эксперементы. но ладно повторил, по твоему, как описано с небольшими дополнениями
id автоинкремент ключевое поле.
вношу в поле datetime текущее время.
машина AMD 1300(1400 но частота в биосе занижена) памяти 512, винт взял махтор 80гиг (несколько, и использовать рейд не совсем честно ;о)), вин 2000 про

время внесения 31,255сек вторая попытка 32,056. 3я-34.349 4я-37ю384
итого в базе 4*65535=262140 записей
теперь делаем запрос
INSERT INTO DateTest SELECT Now AS DTime FROM DateTest
(внесет все 262140 повторно)
время выполнения 4.947 сек
в базе 2*262140=524280 записей

по моему нормально.

← →
YurikGL © (2004-07-11 14:10) [9]

> sniknik © (11.07.04 13:45)

Если у автора 1000 записей пускай Access пользует, но я делал телефонный справочник 300 тыс записей, поиск по подстроке в фамилии, например, да и просто вывод всех записей на экран мягко говоря тормозит.

Наверняка можно и запрос оптимизировать и на экран блочно выводить, но не проще другую СУБД взять?

← →
Zlod3y (2004-07-11 15:10) [10]

использование акцесовского автоинкремента не рекомендуется!
!лично я его всегда делаю его вручную во всех своих программах!

YurikGL прав! акцес не совсем подходит для сетевой работы, точнее сказать, вообще не подходит.....по моему лучше оглянуться в сторону 1с: базы по 100-700 метров вполне обычное дело и всё сделано на DBase

У меня нет рейда! :-(
так не честно!

← →
sniknik © (2004-07-11 15:28) [11]

YurikGL © (11.07.04 14:10) [9]
невнимательно читал? 262140 (почти что 300 тыс) добавление 5 сек. у тебя быстрее? и сколько ты твой справочник туды сюды тусуеш?

вот взял ту же таблицу побольше сделал (1048576 записей) - полная выборка - 3.135сек.
выборка с групировкой (узнать за сколько в секунду добавлялась)
SELECT DTime, Count(*) FROM DateTest GROUP BY DTime
- 3.255сек.
попробуй сделать быстреее.

> YurikGL прав! акцес не совсем подходит для сетевой работы, точнее сказать, вообще не подходит.
прав в том что access не сетевой, он декларируется как локальный (так же как и DBase (если конечно нет DBase серверного, но я имею в виду тот что всем доступен - в BDE))
но вот для сети он подходит гораздо больше чем DBase.
1С кстати совсем не пример, его отчеты переведенные в соответствии с SQL оптимизируются по времени в тясячи раз (!!! и это не шутка) т.что 1С это скорее пример как не надо работать с сетевыми базами. (не вериш сходи на "хиппо" 1С-ный форум, почитай)

> У меня нет рейда! :-(
и я его не использовал. именно поэтому, нечестно.

← →
Zlod3y (2004-07-11 15:55) [12]

Пацан поднял реальный вопрос.....это 200-700 метров, а не одна таблица из двух полей с миллионом записей....сам что посоветуешь? я может тоже хочу внять твоему примеру

← →
sniknik © (2004-07-11 17:11) [13]

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

если пугает ограничение в 2гига, то это тоже не проблема базу обшую можно в нескольких mdb-шниках держать.

внимай! ;о))

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

← →
RomanUzmov (2004-07-11 17:18) [14]

Всем привет!

У меня на Access реально, в производственных условиях, работают несколько баз: от 3000 записей до 120000 записей. Приложения написаны на Delphi 5, Delphi 7. Используются ADO И SQL. Баз состоят из множества связанных таблиц от 10 до 50 шт. Всё работает просто замечательно и быстро. Пользователи не жалуются и я сам не вижу причин что-либо менять. Задачи есть локальные и сетевые. Маскимальное число пользователей для сетевой задачи - 7 одновременно работающих человек. Тормозов замечено не было. Единственная проблема в ADO - это крайне не советую использовать TADOTable. Ещё есть особенности при передачи параметров в запросы, но это просто дело привычки. Так что для среднего уровня баз советую.

← →
qq (2004-07-11 20:15) [15]

sql запрос в базе до 500000 записей на access - секунды, 3млн - более минуты на средней машине. постоянно работает - проверять приходиться часто.

← →
YurikGL © (2004-07-11 21:06) [16]

> sniknik © (11.07.04 13:45) [8]

> машина AMD 1300(1400 но частота в биосе занижена) памяти
> 512,

У меня просто PIII-800 :) может поэтому я на IB свой справочник перетащил.

← →
sniknik © (2004-07-11 21:56) [17]

от машины мало что зависит (не до такой степени).
чтобы было понятно, для сравнения проверил с клоном ib - yaffil(то что у меня есть сейчас) на той же конфигурации, простой запрос с аналогичной структурой к милиону записей занимает даже больше времени 5,826сек против 3.135 в аккесс.

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

← →
Danilka © (2004-07-11 22:14) [18]

sniknik © (11.07.04 21:56) [17]
> милиону записей занимает даже больше времени 5,826сек против
> 3.135 в аккесс.

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

А на счет Аццесса, как я понимаю, с него можно легко базу на МС-СКЛ перевести? Все-таки, думаю, штук 5 пользователей на 700МБ аццесовской базе будет им не слишком сладко..

← →
Danilka © (2004-07-11 22:27) [19]

sniknik © (11.07.04 15:28) [11]
> его отчеты переведенные в соответствии с SQL оптимизируются
> по времени в тясячи раз

На три порядка? Честно говоря, сомневаюсь, скорее всего криворукие 1с-овцы делали, вроде меня.
У меня тоже есть отчеты в 1с тормозные, а намного более тяжелые отчеты настоящих профи в 1с выполняются на порядок быстрее чем мои. :))
Я уже говорил как-то: отчет вываливающийся в экселе на 10к строк из 1ГБ базы (торговля, все еще на дбф-ках) за 10 секунд, на атлонеХР1600+. Приносили ко-мне домой показывали. :))

← →
Zlod3y (2004-07-11 22:51) [20]

ладно, не буду кривить душой, посоветую всё-таки парню Акцес через АДО, так проще, да и всё таки скорость выборки на порядок выше чем скорость обновления и добавления записей......думаю, если записи добавлять и удалять записи редко, да ещё регулярно упаковывая, то можно добиться хорошего результата, при условии конечно что одновременно работающих пользователей не будет больше 2-3

> А на счет Аццесса, как я понимаю, с него можно легко базу на МС-СКЛ перевести?
не так уж и легко, отличий много. но конечно полегче чем с IB. а если только простыми запросами пользоваться без "фич" (процедуры конвертации, функции со строками/датами) есть вероятнось что и без переделок обойдется (очень легкая, вероятность ;).

> На три порядка? Честно говоря, сомневаюсь, скорее всего криворукие 1с-овцы делали, вроде меня.
может быть, а может дело в том что dbf-ная? поэтому маленькая разница. (тоже не использованы возможности SQL, которые 1C просто игнорирует)
dbf-ная 1с локально гораздо быстрее чем sql версия.
у меня был отчет в 1С 3 часа считал (за год но результат 24строки , разбивка по часам), и аналог на MSSQL процедурой, укладывался в секунд 30. причем 1С ный только на сервере ставили на ночь, с рабочей станции как попробовал, всю ночь считало и утром его прервал... а SQLный с любой 30сек (понятно почему думаю? ;).

Не специалист, но утверждают, что 1С работает с MSSQL навигационными методами.

sniknik © (11.07.04 23:07) [21]
Круто. Кстати, запрос SQL-ный ты как запускал? Тут мне в голову пришла идея - можно-же спокойно из 1с-ки его и выполнить: "СоздатьОбъект" и т.д., а результат уже оформить средствами 1с-овского отчета. :))
Надо будет попробовать..

Anatoly Podgoretsky © (11.07.04 23:26) [22]
Угу, именно так. Обещают что в 8-й версии уже совсем другая история, но я ее еще не видел, только бетту, которая за 5 минут отжирает 100МБ памяти и умирает с какой-то ошибкой. :))

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

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

Пример
SELECT string
FROM Table
WHERE string not in (
SELECT string2
FROM Table2
ORDER By Length(string2));
Table,Table2 - 10000 записей... string- не ключевое поле длинной 512...
в таких примерах проще и БЫСТРЕЕ!!! сделать 2 Query
и в циклике сравнивать, а не заставлять СУБД 10000 раз выполнять подзапрос...(в ацессе именно так!)

Оптимизируй сравнивай выбирай и используй...
И обсуждать скорость СКЮЭЛ без строчки о таблицах индексах и запросах ТУПО!

← →
ZA (2004-07-12 08:21) [25]

А обойтись без Access, BDE и прочей фигни не пробывали.
Найдите формат для файла базы и напишите собственный обработчик.
Отпадут жалобы на тормоза. Что написали то и получили.

Danilka © (12.07.04 00:25) [23]
> Кстати, запрос SQL-ный ты как запускал?
отдельная программа была, на дельфи, с одним простейшим sql запросом.

> Тут мне в голову пришла идея - можно-же спокойно из 1с-ки его и выполнить: "СоздатьОбъект" и т.д., а результат уже оформить средствами 1с-овского отчета. :))
попробуй получится. ;о) знаю точно, хотя я и не 1С ник, но работаю в фирме где мы тесно связаны и после некоторых проблем и обсуждений наши 1С ники именно так и делают. не все конечно, а с критическими по времени операциями. если хочеш могу даже прислать кусочек, выделю в ert-шник. (доступ через ADO (естественно ;о)), уже года два как пользуем, а родоначальником был как раз тот простенький отчет, с него пошло обсуждение скорости и т.д.)

> только бетту, которая за 5 минут отжирает 100МБ памяти и умирает с какой-то ошибкой. :))
у нас официальная она не мрет. ;о)

> И обсуждать скорость СКЮЭЛ без строчки о таблицах индексах и запросах ТУПО!
мы не обсуждали сложные запросы а те что из тейбла растут, т.е. типа SELECT * FROM Table
а они от индексов не зависят. впрочем я бы тоже был бы за конкретику.
а твой запрос кстати можно и побыстрее сделать (попробовать, просто не уверен со стрингами), через обьеденение (left join, выбрать то где null), если получится будет быстрее чем ты в цикликах сравниваеш.

to sniknik
а если не TADOTable то что ещё??? Я пересел на mdb в связи с необходимостью. Вот и не знаю, что мона использовать вместо ADOTable

F1 + TAdo и смотреть что есть по этим первым буквам, дальше читать, там написано, что надо использовать, а что не надо. И почему это не надо существует.

sniknik © (12.07.04 08:28) [26]
> если хочеш могу даже прислать кусочек, выделю в ert-шник.
> (доступ через ADO (естественно ;о)), уже года два как пользуем,

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

Slym © (12.07.04 07:14) [24]

SELECT string
FROM Table
WHERE string not in (
SELECT string2
FROM Table2
ORDER By Length(string2));

брр. а зачем выделеная часть? конечно, возможно парсер запроса забъет на нее, но все-таки, интересно :)

кстати, можно его так переписать:
SELECT string
FROM Table
WHERE NOT EXISTS (SELECT 1 FROM Table2 WHERE string2 = Table.string)
Если по Table2.string2 будет индекс, то шустро отработает.

Большая БД на Access2000 и ADO Найти похожие ветки