Дорогие друзья!
Научите, как вы умудряетесь делать законченные проекты с базами данных.
Во всем слушался вас при выборе стратегии построения базы и алгоритма программы.
Результат шестимесячной работы, круглый ноль.
Вот что произошло: со временем число записей дошло всего до 4500, а все работает уже так медленно, что продолжать не стоит. Там всего 5 полей.
Потом проверил, не в запросе ли дело, но самый простой запрос SELECT * FROM ... выполняется за одну секунду, а с объединением двух или более таблиц, вообще кошмар.
Потом проверил, не в базе ли дело, создал новую базу со столькими же записями. Результат тот же. Я представляю, и нечего там представлять, проверил, что происходит, когда 20000 или 80000 записей, плюс, если запрос понадобится с объединением двух или более таблиц. Мне твердили, что пока число записей до полмиллиона или даже больше, нечего опасаться.
Существуют же базы данных в повседневной жизни. Как их умудряются делать. Или Access и Jet это самые паршивые вещи в этой области. Что тогда лучше брать, посоветуйте. Но “лучше” подразумевает, когда 5 или 10 раз быстрее, так как иначе я не знаю, как этой программой можно пользоваться.

Спасибо за ответ!
Индексов признаюсь, нет. Обязательно займусь ими, параллельно прочту ветку, которую вы указали.
Встречал аналогичную программу, как моя, с использованием Borland Database Engine, кто не будь, пользуется им?

поставил индекс на два поля (на primary стоят автоматический)
эффекта вообще не ощутил.

Alexandr Kochmin
Pv> Существуют же базы данных в повседневной
Pv> жизни. Как их умудряются делать.

Это иллюзия.

--
С уважением
Кочмин Александр

Posted via ActualForum NNTP Server 1.3Извините, что иллюзия?

PVPУвелить скорость можно путем увеличения объема памяти компьютера, например, из 128 М до 256 М, и заменой процессора, например 486 AT на Pentium II .
Если этот ответ содержит иронию хочу сказать, что за каждим вопросом стоит чья-то проблема и не всегда приемлемо ничего не дающие ответы. А если серьезна спрашиваете, то все компьютеры P4, 2400 MHz.
В вопросе с самого начала было подчеркнуто что база не такая сложная и по-моему очень маленькая для того чтобы так медленно работала.

Спасибо Alexandr Kochmin все вами перечисленное, я обязательно учту, хотя не думаю что, все сказанное игнорировано у меня.
Здесь находится структура базы, реальная база чуть-чуть отличается. Пример привел, для того чтобы подчеркнуть, что она не сложная.
Ведущая таблица Docs для каждой операции имеется DocID
DocID присутствует в таблице History, где находится все содержимое, всех операции.
Таблица History в свою очередь имеет ID которое, по полям HistoryID в вспомогательных таблицах связан с дополнительной информацией к записи.
Что с чем связано видно из Relationships которое составлено только для наглядности.

Большое спасибо mir
Я ни как не смог так вставить Screenshot в вопрос.

Уже всем спасибо, что столько времени потеряли.

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

Запросов Канешно много, но приведу два из них.

Все слишком безнадежно, или почему остыл желание помочь?

Alexandr Kochmin
Pv> Автор: Ping-vin
Pv> Все слишком безнадежно, или почему остыл желание помочь?
тебе уже все сказали по этой теме, а ты читать и думать не хочешь, а ждешь, когда же будет "такой компонент, который на форму положил, и все быстро заработало".
Здесь рыбы нет.
--
С уважением
Кочмин Александр

Posted via ActualForum NNTP Server 1.3-Ошибаешься.

iscrafm 1.замени OperationID на 1,-1 и делай SUM(amount*OperationID)
2. Исключи запросы select * from, поля перечисли (select * from a inner join b ..., догадываюсь что возможно и больше есть..).
3. По возможности исключи вложенные запросы. Во втором примере непонятно зачем он нужен такой.
SELECT h.goodsID, SUM(d.operationID*h.amount) FROM
history as H inner join Docs as D on H.docID=D.docID
WHERE d.SourceID = '" & Условие & "' and d.docdate <=" & Условие & "
group by h.goodsID1. OperationID заменить вряд ли смогу, я привел пример для одного условия OperationID, а реально их много (перемещение, реализация и т.д.)
2. В основном так и делаю, но после многочисленных экспериментов это работало бистрее всех.
3. Там вложенный запрос присутствует потому, что в реальной работе происходит выборка двух полей из Docs
Спасибо за ответ!

IgorMЕсли Access на P4, 2400 выбирает 4500 записей из таблице за секунду, то тут запросами ничего не исправить. Для теста, добавил 50000 записей в Docs из Example_1.mdb - никаких тормозов.

Таблицы линкованные? На другом компьютере? Если да, проверяй сеть. Сожми базу. Накати все сервис паки для Jet и Access. И скажи какой версии у тебя Access?Будьте добры, за какое время выбирает у вас первый запрос из 50000.
Я проверял для 20000 и 80000 записей. Первый запрос 4 сек на 20000 записей.

Access 2000. сервис паки не стоят, спасибо, посмотрю в эту сторону.

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

IgorM визуально меньше секунды.я на две секунды согласен , буду искать причини дальше

IgorMКстати, рекомендую избегать использования текстовых полей как ключевых и связей таблиц по ним, на более-менее сложных и объемных запросах это тормоза default.Учту обязательно, если не придется очень многое переделать, по-моему, не придется

Проблема действительно идет от текстовых ключей.

В этом плане у меня такая проблема.
В основном в выборках доминируют поля Goods.f1 и Docs.docsID
они и являются текстовыми.
Обязательно нужно чтобы содержимое этих полей вводил пользователь, а программа следит за их уникальностью. А пользователь вводит как раз текстовые идентификаторы.
Вот, нужен ваш совет, как поступить? Добавить авто счетчики как-то рука не поворачивается.